Security

Available Logging Options

Saqib Ullah — Wed, 12 Dec 2007 23:23:11 GMT

Logging is one the important part of any small or big application and selecting the right logging option is very crucial and the decision is made on the basis of logging time response (if you are working on the real time application like my CRM, Stock application), cost of logging implementation and in last at which level of logging you want in your application is very important. Yesterday I found a very interesting comparison between different available logging options; I felt I should share it with you guys.

Options	Positive Points	Negative Points
Event log	High-level application events (for example start and stop)	Limited in number of events
Performance counters	Use when you have rollup summary information (number of active users) or absolute (simple) values you want to measure (total requests)	Not suitable for complex data
Debug output	Single user code pathing and debugging	Overwhelming if used everywhere
SEH	Good for unexpected exceptions	Can bend your design
System.Diagnostics.Trace	Easy to use	Limited to Web apps
ASP.NET trace	Great for debugging	Fixed functionality
WMI	Widely supported, complementary to other schemes (for example, your event log code can be surfaced through WMI)	More complex to use and install applications with
EIF	Easier to program than WMI	Doesn't expose all of WMI's power
LAB	Common requirements provided: MSMQ logging, DBMS logging	A lot to learn

An Exception 'System.TypeInitializationExpection' has occurred

Saqib Ullah — Mon, 09 Jul 2007 02:46:26 GMT

Yesterday when one of my team members opens his project in Visual Studios 2005 he is getting very strange exception.

Exception:
An Exception 'System.TypeInitializationExpection' has occurred in XXXXXXXX-X-XXXXXXXXXXXXXXXXXX.

Replace X’s with chars and its different on every machine.

Click OK and Visual Studio 2005 is shutdown. Everyone in my team scratch their heads oooooooH! my God what the matter it is. Our project is integrated with Visual Source Safe and every one opens the project from VSS. After checking some files in VSS we found that web.config is updated with the following block of code actually we open tracing in our project

Actual Web.Config file

<system.diagnostics>
<trace autoflush="true" indentsize="2" />
<listners>
<remove name="Default"/>
<add name="TestTrace" type="System.Diagnostics.TextWriterTraceListener, System, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" initializeData="ASHWeb.log" />
</listners>
</system.diagnostics>

There is one bug in the above snippets we actually forget to close <trace autoflush="true"> after </listners>.

Updated Web.Config file:

system.diagnostics>
<trace autoflush="true" indentsize="2">
<listners>
<remove name="Default"/>
<add name="TestTrace" type="System.Diagnostics.TextWriterTraceListener, System, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" initializeData="ASHWeb.log" />
</listners>
</trace>
</system.diagnostics>

Save the web.config file in notepad and open the project in Visual Studio 2005 and this time my project load successfully.

Note:
If you want to test this scenario in your project may be you didn’t get any exception because your project is not integrated with Visual Source Safe this exception occurs only when project integrated with VSS.

Apply Rights on File

Saqib Ullah — Tue, 29 May 2007 00:47:17 GMT

This following code create a file and give right only to the "localAdmin" user in my case “localAdmin” is administrator. Next time if you login from guest account and try to access the same file so you will get error message of access deined because user not have the rights.

using System;

using System.IO;

using System.Data;

using System.ComponentModel;

using System.Security.AccessControl;

using System.Security.Principal;

namespace Permission

{

public partial class CreatePermissoinFile

{

///<summary>

/// Create File function

///</summary>

///<param name="fileName">Name of file</param>

public void CreateFile(string fileName)

{

//localAdmin user has Administrator priviliges

NTAccount user = new NTAccount("localAdmin");

FileSystemAccessRule ar = new FileSystemAccessRule(user, FileSystemRights.FullControl, AccessControlType.Allow);

FileSecurity fs = new FileSecurity();

fs.AddAccessRule(ar);

//Name of the File with extension

//like: test.doc

System.IO.File.Create(fileName, 1000, FileOptions.None, fs);

}

Working

Call CreatePermissionFile class and login from non-administrative account into your computer. Open created file and you will get “Access is denied” error.

Reason

Because login user is non-administrative and doesn’t have right to open and move.

Call assembly from partial trust code

Saqib Ullah — Fri, 13 Apr 2007 21:01:00 GMT

In my last blog we saw the Web application trust levels, how we configure trust level from the application. Strong-named assemblies must be stored in the GAC (short of global assembly cache). By default, strong-named assemblies will not grant access to partially trusted code, because of the visibility of strong-named assemblies in the global assembly cache is high. What going on when partial trusted application call the Full trusted assembly. If the calling assembly marks with the APTCA (short of AllowPartiallyTrustedCallersAttribute) attribute or calling application trust-level set to Full Trust no security exception will throw. Applying the APTCA attribute on the assembly open the luring attacks. It is the responsibilities of the developer to careful evaluates the code and then apply the attribute. Applying the attribute to an assembly without strong-name has no effect.

[assembly: AssemblyKeyFile("..\\..\\keyPair.snk")]
[assembly: AllowPartiallyTrustedCallers]

Note: Apply the above APTCA attribute on the assembly make it callable from the partial trusted caller. Any assembly with AllowPartiallyTrustedCallersAttribute only callable from the fully trusted application.

Internal Working

Very quick questions that come in our mind what is internally going on when APTCA attribute apply to the fully trusted assembly. APTCA in an attribute that simply tell the CLR to remove the implicit LinkDemand. In CAS demand are use to ensure that every caller of the code has been granted (directly or indirectly). Stack walk plays very important role to identify the demanded permission. .Net runtime security walks the call stack, comparing the granted permission of each caller to the permission being demanded. SecurityException throw when the caller found without demanded permission in the stack walk. A Link Demand causes a security check during just-in-time compilation and checks only the immediate caller of the assembly. Permissions are checked only for the immediate caller of code so that why a complete stack walks is not performed.

When this type of demand is performed your will be open for luring attacks. MSDN example “If a method in assembly A is protected by a link demand, a direct caller in assembly B is evaluated based on the permissions of Assembly B. However, the link demand will not evaluate a method in Assembly C if it indirectly calls the method in Assembly A using the method in Assembly B.” The link demand apply only the permission direct callers in the immediate calling assembly must have to link to your code.

When AllowPartiallyTrustedCallerAttribute attribute use on class all security checks function as intended but only block the implicit fully trusted caller demand.

Particle

Here is a simple C# class with AssemblyKeyFile attribute (for strong name) in the AssemblyInfo.cs. Still we do not apply AllowPartiallyTrustedCallers on the assembly.

AssemblyInfo.cs file
[assembly: AssemblyKeyFile("..\\..\\keyPair.snk")]

TestAPTCA.cs file

using System;

using System.Collections.Generic;

using System.Text;

namespace TestAPTCA

{

public class CallFromWeb

{

public string Hello(string name)

{

return "Hello " + name;

}

Compile the class and place it in GAC by using utility from visual studio .Net command prompt gacutil.

e.g. gacutil-i "C:\[Projectpath]\assemblyname.dll

Call Assembly for ASP.Net 2.0 web application

Create simple web application and add reference to the TestAPTCA assembly into the project. I use button and label controls on the page and here is Default.aspx class file code is below.

Defualt.aspx.cs file

using System;

using System.Data;

using System.Configuration;

using System.Web;

using System.Web.Security;

using System.Web.UI;

using System.Web.UI.WebControls;

using System.Web.UI.WebControls.WebParts;

using System.Web.UI.HtmlControls;

using TestAPTCA; //Should Add namespace of TestAPTCA.dll

public partial class _Default : System.Web.UI.Page

{

protected void Button1_Click(object sender, EventArgs e)

{

CallFromWeb myObj = new CallFromWeb();

Label1.Text = myObj.CallMeFromWeb("Saqib");

}

One last important change in the web.config file, add trust level code in the <system.web> element.

<?xmlversion="1.0"?>

<!--

Note: As an alternative to hand editing this file you can use the

web admin tool to configure settings for your application. Use

the Website->Asp.Net Configuration option in Visual Studio.

A full list of settings and comments can be found in

machine.config.comments usually located in

\Windows\Microsoft.Net\Framework\v2.x\Config

-->

<system.web>

<trustlevel="High" />

<!--

Set compilation debug="true" to insert debugging

symbols into the compiled page. Because this

affects performance, set this value to true only

during development.

-->

<compilationdebug="true">

...

When you run the application and click the button you will get the following exception.

Exception Details: System.Security.SecurityException: That assembly does not allow partially trusted callers.

The solution of this exception is to add AllowPartiallyTrustedCallers attribute that is present in the System.Security namespace into AssemblyInfo.cs file.

using System.Reflection;

using System.Runtime.CompilerServices;

using System.Runtime.InteropServices;

using System.Security;

[assembly: ComVisible(false)]

// The following GUID is for the ID of the typelib if this project is exposed to COM

[assembly: Guid("feebc2d0-6460-40cd-9894-1843f50aa1b9")]

[assembly: AssemblyKeyFile("..\\keyPair.snk")]

[assembly: AllowPartiallyTrustedCallers]

...

Remove trust level code <trustlevel="High"/> from the web.config file and again run the application and this time application run without error.

Web Application trust

Saqib Ullah — Wed, 11 Apr 2007 17:03:00 GMT

Full trust

By default, Web applications run with full trust. Full-trust applications are granted unrestricted code access permissions like calling unmanaged code, windows service, event logging, open database connection and Microsoft Messaging queues. When application trust level is set to “Full” it means that the web application only can’t access through the resource that is restricted by the operating system level-security. .Net framework allows us to configure the trust level at the machine and application level <trust>, but in default ASP.Net application it is run under Full trust.

Partial trust

Partial trust applications have restricted permissions, which limit their ability to access secured resources and their trust level set other than “Full”. When trust level is set to Full code, access security is effectively disabled because permission demands do not come in the way of resource access attempts, in other words code access security doesn’t checkl from where the code comes.

Following are the ASP.Net Policy Files

Machine.Config in .net 1.1

<system.web>

</securityPolicy>

<-- level="[Full|High|Medium|Low|Minimal]" -->

</system.web>

</location>

Web.Config in .net 2.0
    <location allowOverride="true">
        <system.web>
            <securityPolicy>
                <trustLevel name="Full" policyFile="internal" />
                <trustLevel name="High" policyFile="web_hightrust.config" />
                <trustLevel name="Medium" policyFile="web_mediumtrust.config" />
                <trustLevel name="Low" policyFile="web_lowtrust.config" />
                <trustLevel name="Minimal" policyFile="web_minimaltrust.config" />
            </securityPolicy>
            <trust level="Full" originUrl="" />
        </system.web>
    </location>

Both version of .net framework allow us to customized the trust level depend upon the environment conditions. Both allow the overriding of the tag in application web.config file. If you want to lock the trust level at machine level simply set false in location tag and now code access security is enable and your application behave depend upon the security policy setting.

I will discuss how to call full trust assembly from partial trust in the next blog.

Password with System.Security.SecureString Class in .Net 2.0

Saqib Ullah — Thu, 30 Nov 2006 05:52:00 GMT

There is a new class, System.Security.SecureString . To understand the purpose of this class, think about eg. a password. You probably never want anyone to see the password, but if you store it in a simple System.String instance there are some security risks. For example, how do you get rid of the value when you've finished with the string? You can set the reference to the string to null , but the value itself is still in the managed heap. Indeed there may be several copies of it lurking around if the garbage collector has moved it during previous collections. Bluntly, the heap was never designed to guard against someone going through it with a memory dump tool. SecureString solves this kind of issue. Assigning a value to secure string is pretty simple and just like assigning a value to a string, eg: System.Security.SecureString pword = new System.Security.SecureString(); pword = "admin"; pword.Clear(); The value is stored in an encrypted form, and SecureString also has a Clear() method that completely wipes out the data. Extracting the value from a secure string is possible but complicated - and not often done.