Asp.net| Security | security | Access a key advantage of using ASP.net to host multiple Web sites is that the common language runtime supports code access security to help secure server applications. Depending on the evidence of the source of the code (such as evidence with a strong-named assembly or a source URL), the code is assigned to the security Zone classification. If you cannot configure security for each unrelated application that is installed on the public server, the code belonging to one application on the ASP.net page will be able to read files in another application, such as web.config files. Applications that run in full trust are limited only by operating system accounts, which are executed under that account.
By strongly naming an assembly and adding policies for that assembly, you can easily handle code access security for individual assemblies. However, as a result of dynamic page compilation, many asp.net assemblies are generated dynamically, so these assemblies are not strongly named, so additional functionality is required.
asp.net allows you to assign a configurable level of trust to an application that corresponds to a set of predefined permissions. By default (unless the configuration is explicitly changed), the application receives a level of trust commensurate with the evidence they provide. For example, a local application must run with the Full Trust permission set in the MyComputer zone, and an application on a universal Naming convention (UNC) share must be used in the Intranet zone LocalIntranet Restrict permission set runs. If you want to run a WEB application at a level below full trust, you must implement a partial trust policy by using a predefined level of trust defined in the ASP.net trust level and policy file.
You can override the default behavior and associate the application with a given security policy by using the following configuration settings.
<location path= "MyApp" allowoverride= "false" ><trust level= "High" originurl= "http://www.contoso.com"/> </location>
The <trust> configuration tag can be applied to any application root directory in the machine level or hierarchy.
If you want to set policy for the entire site, you can do so by specifying the root directory of the site as the path location, as shown below.
<location path= "Contososite" allowoverride= "false" ><trust level= "High" originurl= "http://www.contoso.com" /></location>
If you do not want your application to be able to specify their own level of trust (which is the case in most shared server installations), you should be careful when using the allowoverride property to specify the <location> directive.
The following table lists the properties supported by the <trust> element Default.
Property |
Description |
values supported by default |
Level |
Specifies the security zone in which the application will run. |
Full, high, Medium, low, and minimal. |
OriginUrl |
Allows the administrator to set the URL of the source of the application. This allows permissions that depend on the host concept to work correctly |
The properly formatted HTTP URL. |
By default, permissions granted to policies that are associated with different security levels appear in the following table.
|
Level |
Permissions |
completely |
High |
in |
Low |
Minimum |
AspNetHostingPermission |
Completely |
High |
In |
Low |
Minimum |
Environment |
Un |
Un |
READ: TEMP, TMP, OS, USERNAME, COMPUTERNAME |
|
|
FileIO |
Un |
Un |
Read, write, append, path discovery: Application directory |
Read, PATH discovery: Application directory |
|
IsolatedStorage |
Un |
Un |
AssemblyIsolationByUser, Unrestricted user quotas |
1 MB quota (may vary for individual sites), AssemblyIsolationByUser |
|
Reflection |
Un |
ReflectionEmit |
|
|
|
Registry |
Un |
|
|
|
|
Security |
Un |
execution, assertion, control body, control thread, remoting configuration |
execution, assertion, control body, control thread, remoting configuration |
Perform |
Perform |
Socket |
Un |
Un |
|
|
|
WebPermission |
Un |
Un |
Connect to the original host (if configured) |
|
|
Dns |
Un |
Un |
Un |
|
|
Printing |
Un |
Default printing |
Default printing |
|
|
OleDbPermission |
Un |
|
|
|
|
SqlClientPermission |
Un |
Un |
Allowblankpassword=false |
|
|
EventLog |
Un |
|
|
|
|
Message Queue |
Un |
|
|
|
|
Service Controller |
Un |
|
|
|
|
Performance Counters |
Un |
|
|
|
|
Directory Service |
Un |
|
|
|
|
Un = Unrestricted
blank = no permission
If a permission level is available but not explicitly proposed in security policy, applications running with the full trust level can use it (because they have a full Trust permission set). Applications that run with the lower trust level will not be able to use resources that are protected by explicit permissions unless you explicitly change the policy to allow it to be used.
As shown in the table, The high trust application has read/write access to the files located in its application directory, and the low trust application has read-only access to the files located in its application directory. Because FileIO permissions depend on the physical path (for example c:\MyAppPath
), ASP.net uses tagged statements in the policy file that are replaced at run time by the relevant path information of the application.
Note thatWebPermission allows applications to connect to the original host. This mechanism works in asp.net by providing optional OriginUrl properties in the <trust> part of a given application. The originurl property is used to replace the
$OriginHost $ variable in the policy file, as shown in the following code in Web_hightrust.config.
<ipermission class= "WebPermission" version= "1" ><connectaccess><uri uri= "$OriginHost $"/></ Connectaccess></ipermission>
socketpermission Gets the hostname or a dotted IP string (possibly with a wildcard character),WebPermission gets a regular expression that includes the protocol (for example http://backendmachine/.*
). If you want to make changes to this, you can use the permissions you want to change the policy file (or create a new policy file by copying the default settings). For example, you can change the socketpermission section from the asp.net named permission set to grant a TCP socket connection to "Backend1" and "Backend2" on port 8080, as shown below.
<ipermission class= "SocketPermission" version= "1" ><connectaccess><endpoint host= "Backend1" transport= "TCP" port= "8080"/><endpoint host= "Backend2" transport= "tcp" port= "8080"/></connectaccess ></IPermission>
Source: MSDN