ASP.NET Policy | Improving Web Application Security: Threats and Countermeasures

Code access security policy is hierarchical and is administered at multiple levels. Policy can be created for the enterprise, machine, user , and application domain levels. ASP.NET code access security policy is an example of application domain-level policy.

Settings in a separate XML configuration file define the policy for each level. Enterprise, machine, and user policy can be configured using the Microsoft .NET Framework configuration tool, but ASP.NET policy files must be edited manually using an XML or text editor.

The individual ASP.NET trust-level policy files say which permissions might be granted to applications configured at a particular trust level. The actual permissions that are granted to an ASP.NET application are determined by intersecting the permission grants from all policy levels, including enterprise, machine, user, and ASP.NET (application domain) level policy.

Because policy is evaluated from enterprise level down to ASP.NET application level, permissions can only be taken away. You cannot add a permission at the ASP.NET level without a higher level first granting the permission. This approach ensures that the enterprise administrator always has the final say and that malicious code that runs in an application domain cannot request and be granted more permissions than an administrator configures.

For more information about policy evaluation, see Chapter 8, "Code Access Security in Practice."

Inside an ASP.NET Policy File

To see which permissions are defined by a particular trust level, open the relevant policy file in Notepad or (preferably) an XML editor and locate the "ASP.NET" named permission set. This permission set lists the permissions that are configured for the application at the current trust level.

Note	You will also see the "FullTrust" and "Nothing" permission sets. These sets contain no permission elements because "FullTrust" implies all permissions and "Nothing" contains no permissions.

The following fragment shows the major elements of an ASP.NET policy file:

 <configuration>     <mscorlib>         <security>             <policy>                 <PolicyLevel version="1">                     <SecurityClasses>                       ... list of security classes, permission types,                          and code group types ...                     </SecurityClasses>                     <NamedPermissionSets>                       <PermissionSet Name="FullTrust" ... />                       <PermissionSet Name="Nothing" .../>                       <PermissionSet Name="ASP.NET" ...                         ... This is the interesting part ...                         ... List of individual permissions...                             <IPermission                                      class="AspNetHostingPermission"                                     version="1"                                     Level="High" />                             <IPermission                                     class="DnsPermission"                                     version="1"                                     Unrestricted="true" />                           ...Continued list of permissions...                       </PermissionSet>                 </PolicyLevel version="1">             </policy>         </security>     </mscorlib> </configuration>

Notice that each permission is defined by an <IPermission> element, which defines the permission type name, version, and whether or not it is in the unrestricted state.

Permission State and Unrestricted Permissions

Many permissions include state, which is used to fine-tune the access rights specified by the permission. The state determines precisely what the permission allows your application to do. For example, a FileIOPermission might specify a directory and an access type (read, write, and so on). The following permission demand requires that calling code is granted read permission to access the C:\SomeDir directory:

 (new FileIOPermission(FileIOPermissionAccess.Read, @"C:\SomeDir")).Demand();

In its unrestricted state, the FileIOPermission allows any type of access to any area on the file system (of course, operating system security still applies). The following permission demand requires that the calling code be granted the unrestricted FileIOPermission :

 (new FileIOPermission(PermissionState.Unrestricted)).Demand();

The ASP.NET Named Permission Set

ASP.NET policy files contain an "ASP.NET" named permission set. This defines the set of permissions that is granted by application domain policy to associated applications.

ASP.NET policy also introduces a custom AspNetHostingPermission , which has an associated Level attribute that corresponds to one of the default levels. All public types in the System.Web and System.Web.Mobile are protected with demands for the Minimum level of this permission. This risk mitigation strategy is designed to ensure that Web application code cannot be used in other partial-trust environments without specific policy configuration by an administrator.

Substitution Parameters

If you edit one of the ASP.NET policy files, you will notice that some of the permission elements contain substitution parameters ($AppDirUrl$, $CodeGen$, and $Gac$). These parameters allow you to configure permissions to assemblies that are part of your Web application, but are loaded from different locations. Each substitution parameter is replaced with an actual value at security policy evaluation time, which occurs when your Web application assembly is loaded for the first time. Your Web application might consist of the following three assembly types:

Private assemblies that are compiled at build time and deployed in the application's bin directory

Important

This type of assembly cannot be strong named. Strong named assemblies used by ASP.NET Web applications must be installed in the global assembly cache. This restriction is necessary because of the internal workings of the multi-application domain worker process.

Dynamically compiled assemblies that are generated in response to a page request
Shared assemblies that are loaded from the computer's global assembly cache

Each of these assembly types has an associated substitution parameter, which Table 9.2 summarizes.

Table 9.2: ASP.NET Code Access Security Policy Substitution Parameters
Parameter	Represents
$AppDirUrl$	The application's virtual root directory. This allows permissions to be applied to code that is located in the application's bin directory. For example, if a virtual directory is mapped to C:\YourWebApp, then $AppDirUrl$ would equate to C:\YourWebApp.
$CodeGen$	The directory that contains dynamically generated assemblies (for example, the result of .aspx page compiles). This can be configured on a per application basis and defaults to %windir%\Microsoft.NET\Framework\{version}\Temporary ASP.NET Files. $CodeGen$ allows permissions to be applied to dynamically generated assemblies.
$Gac$	Any assembly that is installed in the computer's global assembly cache (GAC) (%windir%\assembly). This allows permissions to be granted to strong named assemblies loaded from the GAC by the Web application.