Authorizing Code | Improving Web Application Security: Threats and Countermeasures

Code access security allows you to authorize the code that calls your assembly. This reduces the risk of malicious code successfully calling your code. For example, you can use identity permissions to restrict calling code based on identity evidence, such as the public key component of its strong name . You can also use explicit code access permission demands to ensure that the code that calls your assembly has the necessary permissions to access the resource or perform the privileged operation that your assembly exposes.

Usually, you do not explicitly demand code access permissions. The .NET Framework classes do this for you, and a duplicate demand is unnecessary. However, there are occasions when you need to issue explicit demands, for example, if your code exposes a custom resource by using unmanaged code or if your code accesses cached data. You can authorize code in the following ways:

Restrict which code can call your code .
Restrict inheritance .
Consider protecting cached data .
Protect custom resources with custom permissions .

Restrict Which Code Can Call Your Code

A method marked as public can be called by any code outside of the current assembly. To further restrict which other code can call your methods , you can use a code access security identity permission demand as shown in the following example.

 public sealed class Utility {   // Although SomeOperation() is a public method, the following    // permission demand means that it can only be called by assemblies    // with the specified public key.    [StrongNameIdentityPermission(SecurityAction.LinkDemand,                                  PublicKey="00240000048...97e85d098615")]   public static void SomeOperation() {} }

The above code shows a link demand. This results in the authorization of the immediate caller. Therefore, your code is potentially open to luring attacks, where a malicious assembly could potentially access the protected resources or operations provided by your assembly through a trusted intermediary assembly with the specified strong name.

Depending on the nature of the functionality provided by your class, you may need to demand another permission to authorize the calling code in addition to using the identity-based link demand. Alternatively, you can consider using a full demand in conjunction with the StrongNameIdentityPermission , although this assumes that all code in the call stack is strong name signed using the same private key.

Note	Issuing a full stack walk demand for the StrongNameIdentityPermission does not work if your assembly is called by a Web application or Web service. This is because it is not possible to strong name the dynamically compiled classes associated with ASP.NET Web applications or Web services.

Task To extract a public key from an assembly

Run the following command to obtain a hex representation of a public key from an assembly:
```
 secutil -hex -strongname yourassembly.dll 
```

Task To extract the public key from a key pair file

Generate the key pair file with the following command:
```
 sn -k keypairfile 
```
Extract the public key from the key pair file:
```
 sn -p keypairfile publickeyfile 
```
Obtain a hex representation of the public key:
```
 sn -tp publickeyfile > publickeyhex.dat 
```

Restrict Inheritance

If your class is designed as base class, you can restrict which other code is allowed to derive from your class by using an inheritance demand coupled with a StrongNameIdentityPermission as shown in the following example. This prevents inheritance of your class from any assembly that is not signed with the private key corresponding to the public key in the demand.

 // The following inheritance demand ensures that only code within the  // assembly with the specified public key (part of the assembly's strong // name can sub class SomeRestrictedClass [StrongNameIdentityPermission(SecurityAction.InheritanceDemand,                               PublicKey="00240000048...97e85d098615")] public class SomeRestrictedClass { }

Consider Protecting Cached Data

If you access a resource by using one of the .NET Framework classes, a permission demand appropriate for the resource type in question is issued by the class. If you subsequently cache data for performance reasons, you should consider issuing an explicit code access permission demand prior to accessing the cached data. This ensures the calling code is authorized to access the specific type of resource. For example, if you read data from a file and then cache it, and you want to ensure that calling code is authorized, issue a FileIOPermission demand as shown in the following example.

 // The following demand assumes the cached data was originally retrieved from // C:\SomeDir\SomeFile.dat new FileIOPermission(FileIOPermissionAccess.Read,                       @"C:\SomeDir\SomeFile.dat").Demand(); // Now access the cache and return the data to the caller

Protect Custom Resources with Custom Permissions

If you expose a resource or operation by using unmanaged code, you should sandbox your wrapper code and consider demanding a custom permission to authorize the calling code.

Full trust callers are granted the custom permission automatically as long as the permission type implements the IUnrestrictedPermission interface. Partial trust callers will not have the permission unless it has been specifically granted by code access security policy. This ensures that non-trusted code cannot call your assembly to access the custom resources that it exposes. Sandboxing also means that you are not forced to grant the powerful UnmanagedCodePermission to any code that needs to call your code.

For more information about calling unmanaged code, see the "Unmanaged Code" section later in this chapter. For an example implementation of a custom permission, see "How To: Create a Custom Encryption Permission" in the "How To" section of this guide.