Compartir a través de


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 (CAS) to help protect Web 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. For information about Code Access Security, see Code Access Security Basics.

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.

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.

Homogenous Application Domains

By default, ASP.NET partial-trust application domains are homogeneous. Homogeneous application domains are partial-trust application domains that define a shared permission set for running code. This results in a constrained set of possible permissions for code that is running in a partial-trust application domain. It also means that the application-domain trust boundary is itself associated with a partial-trust grant set. In a homogeneous application domain that is hosted in ASP.NET, code that can be loaded is associated with one of two permission sets. Code either runs with full trust (code ffrom the GAC always runs in full trust), or code runs with the partial-trust permission set that is defined by the current trust-level setting.

After you install ASP.NET the computer contains two sets of ASP.NET partial-trust policy files. The ASP.NET 4 CAS model uses one set. The other set is used when you configure your application to use the CAS model that is provided in versions earlier than ASP.NET 4. For more information, see Code Access Security in ASP.NET 4 Applications.

The trust Configuration Element

The trust configuration element specifies a trust level. The setting can apply to the computer (machine) level. In that case, every ASP.NET application runs at that trust level. Or the setting can apply to any application root directory in the hierarchy. In that case, the trust level applies to the specific ASP.NET application.

If you want to set policy for a specific application, you can do so by editing the application Web.config file as shown in the following example:

<trust level="High" />

However, if you want to set policy at a higher level (for example, the root of a Web site that has child applications) you can disallow child applications from changing the trust level setting by using a location element as shown in the following example:

<location path="ContosoSite" allowOverride="false">
  <trust level="High" />
</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, we recommend that you set the level attribute of the trust configuration element to Medium.

The trust element provides a LegacyCasModel attribute, which is set to false by default. Setting this attribute to true configures an ASP.NET application to use most (although not all) the ASP.NET CAS behavior from versions of earlier than ASP.NET 4.

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.The default is Full.

TrustSection.LegacyCasModel

Gets or sets a value that indicates whether legacy code access security is enabled.

true or false. The default is false.

originUrl

Specifies a URL or a URL pattern that is allowed connect access. Types in the System.Net namespace use this attribute as part of the security checks that are performed when types in the namespace make HTTP connections. 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.

Note

By default, the ASP.NET 4 CAS configuration enables you to explicitly grant unrestricted WebPermission permissions. This eliminates the need to use the OriginUrl attribute.

Well-formed HTTP URLs, or the regular expression-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

AspNetHostingPermission

Full

High

Medium

Low

Minimal

ConfigurationPermission

Unrestricted

Unrestricted

No permission

No permission

No permission

DnsPermission

Unrestricted

Unrestricted

Unrestricted

No permission

No permission

EnvironmentPermission

Unrestricted

Unrestricted

Read: TEMP, TMP, OS, USERNAME, COMPUTERNAME

No permission

No permission

FileIOPermission

Unrestricted

Unrestricted

Read, Write, Append, PathDiscovery:Application Directory

Read, PathDiscovery:Application Directory

No permission

IsolatedStorageFilePermission

Unrestricted

Unrestricted

AssemblyIsolationByUser, Unrestricted UserQuota

1 MB UserQuota (can be changed for individual sites), AssemblyIsolationByUser

No permission

PrintingPermission

Unrestricted

DefaultPrinting

DefaultPrinting

No permission

No permission

ReflectionPermission

Unrestricted

ReflectionEmit

and RestrictedMemberAccess.

RestrictedMemberAccess

No permission

No permission

RegistryPermission

Unrestricted

Unrestricted

No permission

No permission

No permission

SecurityPermission

Unrestricted

Execution, ControlPrincipal, ControlThread, RemotingConfiguration

Execution, ControlPrincipal, ControlThread, RemotingConfiguration

Execution

Execution

SmtpPermission

Unrestricted

Connect

Connect

No permission

No permission

SocketPermission

Unrestricted

Unrestricted

No permission

No permission

No permission

WebPermission

Unrestricted

Unrestricted

Unrestricted

No permission

No permission

SqlClientPermission

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 that are running with Full permissions can always use it. Applications that are running with lower trust levels will not be able to use resources unless you grant them explicit permissions by changing 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.

Note

By default, ASP.NET grants unrestricted WebPermission for ASP.NET Medium trust application.

See Also

Concepts

Code Access Security in ASP.NET 4 Applications

Other Resources

ASP.NET Web Application Security