ASP. NET code access security)

-

I wrote an article about ASP. Net Program permissions two days ago. I will continue to discuss with you today.CodeAccess Security.

Code access security, as its name implies, is used to restrict code. It can limit whether the code can be executed, and then restrict ASP. NETProgramWhat operations can be performed. For example, CAS prohibits you from using fileiopermission, so ASP. net programs cannot perform Io operations. Similarly, if you are restricted to use sqlclientpermission, ASP. NET programs cannot perform SQL server operations.

CAS defines five different levels by default, which are full, high, medium, low, and minimal. From full to minimal, the permission is getting lower and lower. Basically everything can be done at full level, while at minimal level, only the most basic mangered code can be executed. In our ASP. in the. NET program, the trust level is the web under the root directory. for example, <trust level = "full"/>. The default value is full level. Today, we will talk about how to use CAs to protect the server as a host admin role. There are several steps as follows:

1) determine the operations required by ASP. NET programs on the server.
2) select the most appropriate level from the predefined 5 levels.
3) if not, define a level.
4) The definition level cannot be overwritten.
5) test results.

 

Step 1: Identify the operations required by ASP. NET programs on the server. This is determined by the host Admin. I have no experience in this regard. I will not discuss it here. P.s. If you want to know what permissions your ASP. NET program requires, you can view them using a tool that comes with. NET Framework. This tool is called permissions calculator tool. We can call it through the. NET Framework command window:

Input: percalc-show D: \ myprojects \ job \ bin \ job. dllEnter

Result: The tool automatically analyzes the permissions required by any method of each type in the Assembly and outputs the results to the XML file in the same directory. For example:

 

Step 2: select the most appropriate level from the predefined 5 levels. You can select the most appropriate level, such as high and medium.

Step 3: if not, define a level. What if the high level is higher than the required permissions and medium is smaller than the required permissions (e.g. registrypermission? In this case, we can consider customizing a level. To simplify the process, we can copy the entire medium policy and add registrypermission to it, which becomes our own custom level.

All configuration files of different levels can be found in the c: \ windows \ Microsoft. NET \ framework \ v2.0.50727 \ config directory. To customize a machine-level configuration, we can create a new XML file named custom. config in this directory and copy the content of the web_mediumtrust file. In this way, our custom level has the same permissions as medium. To have higher permissions, We need to manually add registrypermission. This process is divided into three steps:

1) Add this code in <securityclass> section:

Code
<SecurityclassName= "Registrypermission"
Description= "System. Security. permissions. registrypermission,
Mscorlib, version = 2.0.0.0, culture = neutral,
Publickeytoken = b77a5c561934e089"/>

2) add this Code in the following section:

Code
< Permissionset
Class = "Namedpermissionset"
Version = "1"
Name = "ASP. NET" >

< Ipermission
Class = "Registrypermission"
Version = "1"
Unrestricted = "True"   />

</ Permissionset >

3) define the Custom Level to machine-level Web. config:

Code
< 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 Name = "Low" Policyfile = "Web_lowtrust.config"   />
< Trustlevel Name = "Minimal" Policyfile = "Web_minimaltrust.config"   />
< Trustlevel Name = "Custom" Policyfile = "Custom. config"   />
</ SecurityPolicy >
< Trust Level = "Full" Originurl = ""   />
</ System. Web >
</ Location >

 

Step 4: The definition level cannot be overwritten. We only need to set AllowOverride to false.

Step 5: test the effect. You can create an ASP. Net program on the local machine and deploy it to the local IIS. Then, you can test whether the code that can be accessed only at full level or high level can be accessed now. Besides the medium level code, can registrypermission be accessed.

P.s. Here is a very good msdn article to explain in detail cas, this article also referred to thisArticle.

Have a nice day!