ASP.NET Code Access Security
One of the benefits of using ASP.NET to host multiple Web sites is support in the common language runtime (CLR) for code access security to help protect server applications. Code is assigned to a security zone classification based on evidence about the code's origin, such as a strong name for an assembly or the code's URL of origin.
Applications that run with full trust can still be constrained by NTFS file permissions, database permissions, and so on using the Windows account (the ASP.NET process identity) under which they are executing. For more information, see Configuring ASP.NET Process Identity.
In general, you can configure code access security for an individual assembly by making it a strong-named assembly and by adding security policy for that assembly. However, many ASP.NET assemblies are dynamically generated during page compilation and therefore are not strongly named, so you must configure security policy for those assemblies indirectly. Additionally, because ASP.NET supports no-compile applications, assembly-based evidence is not supported. Because ASP.NET applications include the concept of directory structures, it is much easier to configure code access security based on categories of ASP.NET applications as opposed to manually configuring the .NET Framework to work separately with each ASP.NET application on a computer separately.
For each application, ASP.NET lets you assign a configurable trust level that corresponds to a predefined set of permissions. By default, applications are assigned a trust level according to the evidence they present. If you want to run a Web application with less than the Full permission set, you must use one of the predefined trust levels defined in ASP.NET Trust Levels and Policy Files to enforce a partial trust policy.
You can use the following configuration settings in the application's Web.config file to override the default behavior and associate an application with a given security policy. Place these settings in the Web.config file under the configuration element.
<location path="SampleApp" allowOverride="false">
<trust level="High"
originUrl="https://www.contoso.com"/>
</location>
The trust configuration element can apply to the machine level (in which case every ASP.NET application runs at that trust level) or to any application root directory in the hierarchy (in which case the trust level applies to the specific ASP.NET application). If you want to set policy for an entire site, you can do so by editing the Web.config file for the root application of the site and specifying the root of the site as the path location, as in the following example:
<location path="ContosoSite" allowOverride="false">
<trust level="High"
originUrl="https://www.contoso.com"/>
</location>
It is recommended that you set the level attribute of the trust configuration element to High for sites that are trusted. For sites that are not trusted, such as a Web server that hosts sites that run code from an external customer, it is recommended that you set the level attribute of the trust configuration element to Medium. For a detailed description of running ASP.NET applications in Medium trust, see "How To: Use Medium Trust in ASP.NET 2.0" at Patterns and Practices (PAG): Security Guidance for Applications.
If you are configuring trust settings at the machine or site level, you typically set the allowOverride attribute to false in the location element, so that individual applications are not able to specify their own trust level. This is typical in shared server installations.
The following table lists the default supported attributes for the trust configuration element.
Attribute |
Description |
Supported values |
|---|---|---|
level |
Specifies the security zone under which the application will run. |
Full, High, Medium, Low, and Minimal. |
originUrl |
Specifies a URL or URL pattern that is allowed for connect access using classes in the System.Net namespace. If present, this attribute can be used to check permissions for some objects, such as a WebRequest instance, that allow connectivity to various network locations. For example, you could configure this attribute with the host name of servers in a Web farm so that ASP.NET pages could call Web services deployed in the same Web farm as the Web application. |
Well-formed HTTP URLs, or the regex-based syntax that is supported by WebPermissionAttribute. |
The following table lists permission types supported by the CLR and the default policy for each permission under different trust levels.
Permission |
Full |
High |
Medium |
Low |
Minimal |
|---|---|---|---|---|---|
Full |
High |
Medium |
Low |
Minimal |
|
Unrestricted |
Unrestricted |
No permission |
No permission |
No permission |
|
Unrestricted |
Unrestricted |
Unrestricted |
No permission |
No permission |
|
Unrestricted |
Unrestricted |
Read: TEMP, TMP, OS, USERNAME, COMPUTERNAME |
No permission |
No permission |
|
Unrestricted |
Unrestricted |
Read, Write, Append, PathDiscovery:Application Directory |
Read, PathDiscovery:Application Directory |
No permission |
|
Unrestricted |
Unrestricted |
AssemblyIsolationByUser, Unrestricted UserQuota |
1 MB UserQuota (can be changed for individual sites), AssemblyIsolationByUser |
No permission |
|
Unrestricted |
No permission |
No permission |
|||
Unrestricted |
No permission |
No permission |
No permission |
||
Unrestricted |
Unrestricted |
No permission |
No permission |
No permission |
|
Unrestricted |
Execution, Assertion, ControlPrincipal, ControlThread, RemotingConfiguration |
Execution, Assertion, ControlPrincipal, ControlThread, RemotingConfiguration |
|||
Unrestricted |
No permission |
No permission |
|||
Unrestricted |
Unrestricted |
No permission |
No permission |
No permission |
|
Unrestricted |
Unrestricted |
Connect to origin host (if configured) |
No permission |
No permission |
|
Unrestricted |
Unrestricted |
Unrestricted |
No permission |
No permission |
|
Event Log |
Unrestricted |
No permission |
No permission |
No permission |
No permission |
Message Queue |
Unrestricted |
No permission |
No permission |
No permission |
No permission |
Service Controller |
Unrestricted |
No permission |
No permission |
No permission |
No permission |
Performance Counters |
Unrestricted |
No permission |
No permission |
No permission |
No permission |
Directory Service |
Unrestricted |
No permission |
No permission |
No permission |
No permission |
When a permission level is available but is not explicitly mentioned in security policy, applications running with Full permissions can always use it. Applications running with lower trust levels will not be able to use resources unless you grant them explicit permissions by altering the security policy.
As the table shows, application with High permission sets have read/write permission for files in their application directories, and Low trust applications have read-only permission for files in their application directories. Because the FileIOPermission type relies on a physical path (for example, c:\SampleAppPath), ASP.NET uses a tokenized statement in the policy files that is replaced at run time with relevant path information for the application.
The WebPermission type allows the application to connect to the network location defined by the original host attribute, using classes like System.Net.WebRequest. In ASP.NET, you can configure this permission by providing an optional originUrl attribute on the trust section for a given application. The originUrl attribute replaces the $OriginHost$ variable in policy files, as shown in the following section from the Web_hightrust.config file:
<IPermission class="WebPermission" version="1">
<ConnectAccess>
<URI uri="$OriginHost$"/>
</ConnectAccess>
</IPermission>