引子：大家都知道网上出现过诸如《asp.net虚拟主机的重大隐患》等类似介绍Asp.Net的漏洞以及相应的黑客攻击办法的文章，以及诸如Webadmin.aspx类Asp.Net的Webshell,如果您拿去到您的asp.net虚拟主机上测试时您就知道，这东东对C盘有读取权限，以及对整个硬盘都有 修改、删除权限；那这样的话，我们的网站、我的服务器还有什么安全可言？在黑客频频攻击的今天，我们不能不为我们的服务器而担忧...
漏洞原因:大家知道ASP中常用的标准组件:FileSystemObject，这个组件为ASP提供了强大的文件系统访问能力，可以对服务器硬盘上的任何有权限的目录 和文件进行读写、删除、改名等操作。FSO对象来自微软提供的脚本运行库scrrun.dll中。而在Asp.Net中这个问题仍然存在，并且更加难以解决；因为.Net中对系统IO操作功能更加强大,如：组件不再需要用Regsvr32来注册，而是直接在bin目录下就可以直接用了，所以这些功能对开发Asp.Net程序有很大方便是，但却使安全变得更为复杂了....
解决方案：
大家都知道，Asp类木马可以通过对IIS中的虚拟主机采用独立匿名用户来控制FSO组件的安全，让其只能在站类活动，而不能跨站或者危害到其它硬盘的数据(注：如果您不明白可以参考一下本人以前的两篇文章《FSO安全隐患解决办法》; 《ASP木马Webshell之安全防范解决办法》) Asp的安全问题与设置这里不再作讨论，下面我们开始着手Asp.Net木马/WebShell防范方法的讲解：
一、在IIS6.0中，WEB应用程序的工作进程为以进程标识“Network Service”运行。而在IIS5.0中，进程外WEB应用程序则是以“IWAM_服务器名”用户运行行，这个User是普通的本地Guests用户。网上有部份人提出针对此问题用Microsoft .NET Framework Configration设置System.io的对目录读取的权限，但很遗憾经过我们测试没有成功，可能是.net framework1.1机制改了？
Network Service 是Windows Server 2003中的内置帐户。了解IIS5.0上的本地用户帐户(IUSR和IWAM)与这个内置帐户之间的区别是非常重要的。Windows操作系统中的所有帐户都分配了一个SID(安全标识:Security ID）。服务器是根据 SID，而不是与SID相关的名称来识别服务器上所有帐户的，而我们在与用户界面进行交互时，则是使用名称进行交互的。服务器上创建的绝大部分帐户都是本地帐户，都具有一个唯一的 SID，用于标识此帐户隶属于该服务器用户数据库的成员。由于SID只是相对于服务器是唯一的，因此它在任何其他系统上无效。所以，如果您为本地帐户分配了针对某文件或文件夹的 NTFS 权限，然后将该文件及其权限复制到另一台计算机上时，目标计算机上并没有针对这个迁移SID的用户帐户，即使其上有一个同名帐户也是如此。这使得包含NTFS权限的内容复制可能出现问题。内置帐户是由操作系统创建的、一类较为特别的帐户 或组，例如System帐户、Network Service和Everyone 组。这些对象的重要特征之一就是，它们在所有系统上都拥有一个相同的、众所周知的SID。当将分配了NTFS权限的文件复制到内置帐户时，权限在服务器之间是有效的，因为内置帐户的SID在所有服务器上都是相同的。Windows Server 2003 服务中的 Network Service 帐户是特别设计的，专用于为应用程序提供访问网络的足够权限，而且在IIS 6.0中，无需提升权限即可运行Web 应用程序。这对于IIS安全性来说，是一个特大的消息，因为不存在缓冲溢出，怀有恶意的应用程序无法破译进程标识，或是对应用程序的攻击不能进入System用户环境。更为重要的一点是，再也不能形成针对System帐户的“后门”，例如，再也无法通InProcessIsapiApps元数据库项利用加载到Inetinfo的应用程序。我们已经简单的介绍了一下ASP.NET中关于文件IO系统的漏洞的防治方法，这一方法有些繁琐，但是却可以从根本上杜绝一些漏洞，我们讨论的只是很少的一部分，更多的解决放法需要大家共同来探索、学习。
五、解决办法操作步骤：
1、我们将每一个Asp.Net虚拟主机站点都分配一个独立的应用程序池，并赋予不同的权限。下面我就针对此来做一个示例：首先，我们为网站创建两个用户(一个是App_31896.net_User、密码为App_31896.net,一个是IUSR_31896.net_User、密码为IUSR_31896.net）
2、依次打开"计算机管理器"→"系统管理工具"→"本地用户和组"→"用户",然后新增两个用App_31896.net_User与IUSR_31896.net_User密码分别为：App_31896.net与IUSR_31896.net。选择“用户不能更改密码”与“密码永不过期”，然后分别把App_31896.net_User添加到iis_wpg组，把IUSR_31896.net_User添加到Guests组。将用户赶出其它组成员。
3、然后，打开IIS管理员器新建相应的应用程序池。依次打开Internet 信息服务→本地计算机→应用程序池→新建→应用程序池，新建一个名字为App_31896.net的应用程序池。
4、编辑App_31896.net应用程序池的属性→标示→配置→用户名→浏览→把用户名改为我们刚才建立的App_31896.net_Use并输入相应的密码App_31896.net。
5、然后再建立相应的网站。依次打开Internet 信息服务→本地计算机→网站→新建→31896.net的网站，目录为E:\Vhost\31896.net^_^→编辑31896.net网站的属性→主目录→应用程序池→App_31896.net →目录安全性→身份验证和访问控制→编辑，选择我们刚才建立的IUSR_31896.net_User,并输入相应的密码IUSR_31896.netr→保存并退出。
6、最后设定IIS的站点目录权限Acls以及整个服务器系统的安全，这里就不再详细讨论，关于服务器的整体系统安全可以参考下本人的Win Server 2003服务器整体安全技术白皮书。（IIS站点权限参考《FSO安全隐患解决办法》与《ASP木马Webshell之安全防范解决办法》这两篇进行；关于IIS的运行权限请参考《IIS 6.0所需要的默认ACLs权限[即NTFS的硬盘权限]》此文进行）
好了，我们已经简单的介绍了一下ASP.NET中关于文件IO系统的漏洞的防治方法，这一方法虽然有些繁琐，但是却可以从根本上杜绝一些漏洞，这里我们讨论的只是很少的一部分，更多的解决放法需要大家共同来探索、学习。当然如果你发现了更好的办法可别忘了告诉我哟^_^
笔者后记：这里为大家介绍的仅仅是本人在处理ASP.NET木马、Webshell上的一些心得体会。在下一篇中将为大家介绍如何简简单单的对系统某些相应的服务进行降权处理，以防止溢出、提权等攻击、加强服务器系统的安全。其实服务器、系统的安全是个整体的概念；远远不止这些,可能你其中有一小点的疏忽就可以让你的网站、甚至服务器沦陷。因此安全策略必需走防患未然的道路，任何一个小地方都不能马虎、今天关于防Asp.Net安全隐患小技巧就为大家介绍到这里...
