Using code access security in ASP.net __.net

Release Date: 12/15/2004 | Renew Date: 12/15/2004

View all Security Guide topics

Microsoft Corporation Overview of this unit

Code access security is a resource constraint model that enables administrators to determine whether specific code and how to access the specified resource and perform other privileged operations. The focus of this module is on ASP.net code access security policy configuration, which explains how to overcome some of the major hurdles that you might encounter when developing partial-trust WEB applications.

This module details the actual elements of code access security, and you will learn how to develop a medium-trust Web application that can still use components that require full trust while benefiting from security provided by code access safety.

This module also contains information about how to create a custom ASP.net trust policy and contains two very valuable lists:

•	System assemblies that apply APTCA (AllowPartiallyTrustedCallersAttribute).
•	The default ASP.net policy permissions and trust level. It specifies which key restrictions are imposed on each ASP.net trust level.

Back to the top of the page Target

Through this module can:

•	Learn how the ASP.net policy file works and how to create a custom policy.
•	Develop partial trust WEB applications.
•	Use OLE DB, event logs, Web services, and the registry from a partial-trust Web application.
•	Protect privileged code with a sandbox.
•	Learn when to use sandbox protection and when to customize existing ASP.net trust policies.

Back to the top of the page Application Range

This module applies to the following products and technologies:

•	microsoft®windows®2000 Server and Microsoft Windows server®2003 operating system
•	Microsoft. NET Framework 1.1 and ASP.net 1.1

Back to the top of the page How to use this unit

This module does not cover the basics of code access security. We assume that the reader already has some preliminary knowledge, although the important concepts will be restated in due course. For more information about how code access security works, see the Code Access Security Practices Unit.

Use this module to learn how to securely lock WEB applications with code access and to harden servers against potential attacks.

If you are managing a shared hosting environment or working for an Internet service provider (ISP), you can use code access security to run multiple applications from different companies on the same WEB server:

•	make applications independent of each other . For example, code access security can be used to ensure that Web applications cannot write directories for another Web application.
•	separate the application from the system resources . For example, code access security can restrict access to file systems, the registry, event logs, network resources, and other system resources.

Also note that Windows Server 2003 and Internet Information Services (IIS) 6.0 provide further process independence for WEB applications. Process independent combination of code access security is an application independent recommendation model.

For more information, see the unit "hosted multiple asp.net applications." content of this page

Restrictions on

	This cell overview
	goal
	Application scope
	How to use this module
	Overview
resource access
	Full trust and partial trust
	in asp.net Place code access security
	asp.net policy file
	asp.net policy
	Develop partial trust Web applications
	trust level
	how partial trust Web applications are handled
	custom Policies
	Protect privileged code with sandbox
	determines which approach to use
	Middle degree Trust
	Moderate Trust
	Summary
	Other resources

Back to the top of the page Overview

Traditional user-based security, such as the security provided by the operating system, requires authorization of access to various resources based on the user's identity.

In the Microsoft. NET Framework version 1.1, administrators can configure policies for ASP.net Web applications and Web services, which can be composed of multiple assemblies. They can also grant code access security permissions to allow applications to access specific resource types and perform specific privileged operations.

For example:

•	An administrator may decide that code downloaded from the Internet should not be granted access to any resources, and that a particular company develops WEB application code that should gain greater trust, such as allowing access to file systems, event logs, and Microsoft SQL Server databases.
•	Programs initiated by local administrators are not restricted on this computer. Unfortunately, if the administrator's identity is spoofed and a malicious user can execute code using the administrator's security context, then there is no limit to the malicious user.

Code access security in these areas is important because it can provide more restrictions and security based on the code itself than the users who run the code.

Note Web applications and Web services built with the. NET Framework version 1.0 are always run with unlimited code access permissions. This is not configurable. Return to the top of the page resource access

All resource access from ASP.net applications and managed code is generally limited by the following two security levels:

•

Code access security. This security layer verifies that all code in the current call stack (which has been directed and includes resource access code) has been authorized to access the resource. Administrators can use code access security policy to grant permissions to assemblies. Permissions accurately determine which resource types the assembly can access. The different resource types that you can access correspond to many permission types. These types include file systems, the registry, event logs, directory services, Microsoft SQL Server_, OLE DB data sources, and network resources. For a complete list of code access permissions, see the Code Access Security Practices Unit.

•

operating system/platform security . This security layer verifies that the security context of the requester thread can access the resource. If the line one thread is being emulated, the thread impersonation token is used. Otherwise, the process token is used and the Access Control List (ACL) that is associated with the resource is compared to determine whether the requested operation can be performed and whether the requested resource is accessible.

If a resource is to be successfully accessed, all of the resource types exposed by the. NET Framework classes are protected with code access permissions. Figure 1 illustrates a common set of resource types that WEB applications access, as well as the related code access permissions that are required to access the desired success.

Figure 1. Common resource types and associated permission types accessed from ASP.net Web applications return to the top of the page full trust and partial trust

By default, the Web application runs with full trust. Full-trust Applications Grant Unlimited code access to code access security policies. These permissions include built-in system permissions and custom permissions. This means that code access security will not prevent the application from accessing any protected resource types, as shown in Figure 1. The success or failure of resource access depends entirely on operating system-level security. Web applications running with full trust include all asp.net applications built with the. NET Framework version 1.0. By default,. NET Framework version 1.1 applications run with full trust, but the trust level can be configured to use the< trusts > element, which is described later in this module.

If an application is configured as a trust level other than "full", it is called a partial-trust application. Permissions for partial-trust applications are restricted, and this permission restricts their ability to access protected resources.

important Web applications built with the. NET Framework version 1.0 are always running with full trust, because types in system.web require full trust of callers. Return to the top of the page configure code access security in ASP.net

By default, the Web application runs with full trust with unlimited permissions. To modify the trust level of code access security in ASP.net, you must set up a switch in Machine.config or Web.config to configure the application as a partial-trust application. Configuring the trust level

The < trust >element in Machine.config controls whether code access security is enabled for WEB applications. Open Machine.config, search for "", you can see the following content.

<system.web>
  <!--level= "[full| high| medium| low| Minimal] "-->
  <trust level=" full "originurl=" "/>
</system.web>
  

When the trust level is set to full, code access security is actually disabled, because permission requirements do not prevent attempts to access resources. This is the only choice for asp.net Web applications built on the. NET Framework version 1.0. From "full" to "minimal", each level deletes more permissions, further limiting the application's ability to access protected resources and perform privileged operations. Each level provides a greater degree of application independence. Table 1 illustrates the predefined trust levels and identifies the major limitations compared to the previous level.

Table 1 restrictions imposed by the ASP.net trust level
asp.net trust level	Main limitations
Full	Unlimited permissions. Applications can access any resource that is subject to operating system security restrictions. All privileged operations are supported.
High	Cannot call unmanaged code Cannot invoke service component Cannot write event log Cannot access Microsoft Message Queuing Cannot access OLE DB data source
Medium	In addition to the above, file access is limited to the current application directory, and registry access is not allowed.
Low	In addition to the above, the application cannot connect to SQL Server, and the code cannot invoke CodeAccessPermission.Assert (that is, security permissions cannot be asserted).
Minimal	Only execute permissions.

Lock Trust Level

If the WEB server administrator wants to use code access security to ensure application independence and to restrict access to system-level resources, administrators must be able to define security policies at the machine level to prevent individual applications from overwriting them.

An application service provider or anyone who is responsible for running multiple Web applications on the same server should lock the trust level for all Web applications. To do this, load the <Trust > elements in the machine.config <location> tag and set the allowoverride property to False, as shown in the following example.

<location allowoverride= "false" >
  <system.web>
    <!--level= "[full| high| medium| low| Minimal] "-->
    <trust level=" Medium "originurl=" "/>
  </system.web>
</location>

You can also use a path property of the <location> element to apply a configuration to a specific site or WEB application that cannot be overwritten. For more information about <location> elements, see the "Securing ASP.net Applications" unit. Back to the top of the page asp.net policy file

Each trust level corresponds to an XML policy file that lists the permission sets granted by each trust level. The policy file is located in the following directory:

%windir%/microsoft.net/framework/{version}/config
  

The trust level corresponds to each policy file through the <trustlevel> element in Machine.config, which is located justabove the < trusts > element, as shown in the following example.

<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
      "Low" name= "policyfile=" Lowtrust.config "/>
      <trustlevel name= Minimal" policyfile= "Web_minimaltrust.config"/>
    Securitypolicy>
    <!--  level= "[full| high| medium| low| Minimal] "-->
    <trust level=" full "originurl=" "/>
  </system.web>
</location>

Note There is no corresponding policy file for the full trust level. This is a special case, just a set of infinite sets that represent all permissions.

The ASP.net policy is fully configurable. In addition to the default policy level, administrators can create custom permission files and configure themwith the < trust > element, which is described later in this module. Policy files related to custom levels must also be defined with the <trustlevel> element in Machine.config. Back to top asp.net policy

Code access security policies are hierarchical and can be managed at multiple levels. We can create policies for enterprise, machine, user, and application domain levels. asp.net code access security policy is an example of application domain-level policy.

The settings in an XML configuration file define policies for each level. Enterprise, machine, and user-level policies can be configured with the Microsoft. NET Framework Configuration tool, but asp.net policy files must be edited manually using either an XML editor or a text editor.

A separate asp.net trust-level policy file can indicate which permissions can be granted to an application configured at a particular trust level. The actual permissions granted to an ASP.net application are made up of all policy levels, including enterprise, machine, user, and ASP. NET (application domain)-level policy is determined by the intersection of the permissions granted by the

Because the policy is computed from the enterprise level down to the ASP.net application level, permissions can only be deleted continuously. If you do not have a higher level to grant permissions first, you cannot add permissions at the asp.net level. This approach ensures that enterprise-class administrators always have the final decision, and that malicious code running in one application domain cannot request and be granted more permissions than the administrator has configured.

For more information about policy calculations, see the Code Access Security Practices Unit. asp.net policy Files

To understand what permissions are defined for a particular trust level, you can open the appropriate policy file in Notepad or the XML editor (better) to find the "asp.net" named permission set. This permission set lists the permissions that are configured for the current trust level application.

Note You can also see the "FullTrust" and "nothing" permission sets. These collections do not contain permission elements, because "FullTrust" means all permissions, and "Nothing" means that no permissions are included.

The following code fragment shows the main elements of a asp.net policy file:

<configuration> <mscorlib> <security> <policy> <policyl Evel version= "1" > <SecurityClasses> ... list of security classes, Permi
                    Ssion 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" unrestr Icted= "true"/> ... Continued list of permissions </PermissionSet> </policylevel version= "1"
 > </policy> </security> </mscorlib> </configuration>

Note that each permission defined by the <IPermission> element defines the permission type name, version, and whether it is in an infinite state. status and unlimited permissions for permissions

Many permissions contain states, and states can be used to fine-tune the access rights specified by permissions. The state accurately determines what the permission allows the application to do. For example,FileIOPermission may specify a directory and an access type (read, write, and so on). The following permissions require that the calling code be granted read access to the C:/somedir directory:

(New FileIOPermission (FileIOPermissionAccess.Read, @ "C:/somedir")). Demand ();
  

In an infinite state,FileIOPermission allows any type of access to any area of the file system (of course, operating system security is still applicable). The following permission requirements require that the calling code be granted unlimited FileIOPermission permissions:

(New FileIOPermission (permissionstate.unrestricted)). Demand ();
  

asp.net named permission set

The ASP.net policy file contains a "asp.net" named permission set. The permission set defines the permission set that the application domain policy grants to the relevant application.

The ASP.net policy also introduces a custom aspnethostingpermissionthat has a related level attribute that corresponds to one of the default levels . All public types in system.web and System.Web.Mobile are protected with the Minimum level requirements for this permission. The purpose of this risk reduction strategy is to ensure that WEB application code cannot be used in other partial-trust environments without the specific policy configuration of the administrator. Replace Parameters

If you have a