18.6 ASP.NET and Code-Access Security

Although they present a simplified development model, ASP.NET applications are fully fledged .NET applications that run on the CLR. ASP.NET pages and associated code-behind modules are compiled into .NET assemblies prior to execution. As such, ASP.NET applications are subject to the runtime's code-access security controls, which we discussed in Chapter 5 through Chapter 9. However, ASP.NET applications represent a different application model than we focused on in those chapters.

With ASP.NET applications, you are not facing the problem of protecting your machines from highly mobile code downloaded from a variety of untrusted and potentially questionable sources. Usually, you are dealing with a smaller number of ASP.NET applications from known sources that are being uploaded to a shared hosting server. Your primary concerns are ensuring that the ASP.NET application code cannot tamper with the operation of the operating system, affect other hosted applications, or gain undesired levels of access to internal network-based resources.

Under the default code-access security policy (which we discussed in Chapter 9), all ASP.NET applications execute with full and unrestricted access, because they run from the local machine. Given the concerns we have just outlined, this is clearly not acceptable. ASP.NET implements code-access security in a way that allows the capabilities of each ASP.NET application to be constrained to a safe and secure level.

To configure the code-access permissions for an ASP.NET application, use the <trust> configuration element, which you can configure at the machine, site, or application level. The level attribute of the <trust> element specifies the name of a predefined trust level to assign to the application. The .NET Framework defines five standard trust levels: Full, High, Medium, Low, and Minimal.

Each named trust level maps to a policy level definition; we discussed policy levels in Chapter 8. Each ASP.NET application runs in its own application domain, and the runtime applies the policy level associated with the trust level to the application domain in which the ASP.NET application is running. This has the effect of controlling the permissions granted to the ASP.NET application.

Table 18-3 lists the names of the standard trust levels and identifies the file that contains its policy level definition. The files are all located in the CONFIG folder of the .NET Framework installation directory. For a complete description of the permissions granted by each trust level, consult the .NET Framework SDK documentation, or look at the contents of the policy file itself.

Table 18-3. ASP.NET trust levels and their policy file mappings

<trustLevel>	Policy file
Full	This trust level does not map to an external policy file, but represents the standard FullTrust named permission set described in Chapter 10.
High	web_hightrust.config.
Medium	web_mediumtrust.config.
Low	web_lowtrust.config.
Minimal	web_minimaltrust.config.

The following Web.config extract from the DotNetSecurity folder shown in Figure 18-1 configures trust levels for two folders. In the first instance, we use the <location> element to configure a Low trust level for the Chapter17 folder. Because we also specify allowOverride="false", all applications below the Chapter17 folder have Low trust and cannot override the setting in their own Web.config files; this is a common approach when hosting multiple applications.

In the second instance, we specify a Medium trust level, which affects all folders and applications below the DotNetSecurity folder (except Chapter 17):

<configuration>   <location path="Chapter17" allowOverride="false">     <trust level="Low"/>   </location>   <system.web>     <trust level="Medium"/>   </system.web> </configuration>

In addition to the standard trust levels defined in Table 18-3, you can define your own using the <securityPolicy> and <trustLevel> configuration elements. The <securityPolicy> element can be specified at the machine, site, or application level, and contains a set of <trustLevel> elements, each defining a mapping between a trust level name and a security policy file.

The following Web.config example shows the definition of two new trust levels named BasicService and PremiumService. Chapter 8 contains all the information you need to build a security policy hierarchy that you can store to disk and assign to a custom ASP.NET trust level:

<configuration>   <system.web>     <securityPolicy>       <trustLevel name="BasicService" policyFile="basic_svc.config"/>       <trustLevel name="PremiumService" policyFile="premium_svc.config"/>     </securityPolicy>   </system.web> </configuration>