ASP. NET Security Policy

I 've been discussing with my colleagues over the past few days how to protect asp.net's webshell.


Author: papaya@80sec.com
First of all, it is certain that ms has a complete set of "Code Access Security" as follows.



By default, all. net web applications inherit the "C: WindowsMicrosoft. NETFrameworkv2.0.50727CONFIGweb. config" configuration file.

<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"/>
</SecurityPolicy>
<Trust level = "Full" originUrl = ""/>
</System. web>
</Location>

The policy can be overwritten with allowOverride = true;
Several built-in policy levels and files,
The default value is FullTrust, while MS's description of fulltrust is: "Therefore, the Full trust level is mapped to an internal handler andASP. NETDoes not add additional policy to the application domain for full-trust applications ."
That is to say, in full mode, no additional security policies will be used. A default permission list is provided. Of course, if it is overwritten, it will be different.


Now we know the shell danger of asp.net, And the protection work is simple. Rewrite security policies should be prohibited if the business is not harmed, or rewrite security policies at lower levels on appropriate nodes. The final task is to configure the security policy. The detailed configuration methods and documentation for MS are provided here.Http://technet.microsoft.com/zh-cn/library/aa302424.aspxIf you are a lazy, you can directly set it to "<trust level =" High "originUrl =" "/>" or lower, at the same time, you can set the website root directory web with the FSO permission of the NT System. config is read-only.

There are several points to remember
0. FullTrust is absolutely dangerous.
1. Do not use shell to overwrite the policy file.
2. exe executed from webshell is not limited by asp.net policies.
3. Reflection is a dangerous method.
4. Taking the time to configure security policies is a permanent task.