Windows Serv
服务器如何防范asp木马
|
[ 2005/05/24 00:50 | by 网络毛毛虫 ]
|
为了更好的理解这一问题的解决方法,我们需要先介绍一下.NET Framework的安全机制。然后再结合我们的实际问题来讨论解决方案。
为了解决安全问题，.NET Framework提供了一种称为代码访问安全性的安全机制。代码访问安全性允许根据代码的来源和代码的标识等属性将代码设置为不同级别的信任代码,同时还详细定义了不同级别的对代码的信任，从而可以详细的对代码设置各自的权限而不是将最大权限赋给所有的代码。使用代码访问安全性，可以减小恶意代码或各种错误的代码带来的严重的系统安全性问题的可能性。您可以设置允许代码执行的一组操作，同样可以设置永远不允许代码执行的一组操作。
实现代码访问安全性的基础就是JIT（运行时编译）和IL（中间代码）。所以所有以公共语言运行库为目标的托管代码都会受益于代码访问安全性。非托管代码则无法完全使用代码访问安全性。
下面我们将介绍一下代码访问安全性实现的各种功能：
代码访问安全性是控制代码对受保护资源和操作的访问权限的一种机制。在 .NET Framework中，代码访问安全性执行下列功能：
· 定义权限和权限集，它们表示访问各种系统资源的权限。
· 使管理员能够通过将权限集与代码组关联来配置安全策略。
· 使代码能够请求运行所需权限以及其他一些有用的权限，以及指定代码绝对不能拥有哪些权限。
· 根据代码请求的权限和安全策略允许的操作，向加载的每个程序集授予权限。
· 使代码能够要求其调用方拥有特定的权限。
· 使代码能够要求其调用方拥有数字签名，从而只允许特定组织或特定站点的调用方来调用受保护的代码。
· 通过将调用堆栈上每个调用方所授予的权限与调用方必须拥有的权限相比较，加强运行时对代码的限制。
为了确定是否已授予代码相应的权限，.NET运行库的安全系统将遍历整个调用堆栈，将每个调用方所授予的权限与目前要求的权限相比较。如果调用堆栈中的任何调用方没有要求的权限，则会引发安全性异常，并会拒绝访问和相应的操作。堆栈步旨在防止引诱攻击；在这种攻击中，受信程度较低的代码调用高度信任的代码，并使用高度信任的代码执行未经授权的操作。在运行时要求所有调用方都拥有权限将影响性能，但对防止代码遭受攻击至关重要。若要优化性能，可以使代码执行较少的堆栈步；但是，任何时候这样做时均必须确保不会暴露安全缺陷。
还存在另外一种代码访问安全性的常见用途，即应用程序将控件从网络 Web 站点直接下载到客户端，这种方式的代码安全性也是可以在客户端进行设置的，根据签名等数据权限证书来确定是不是可以允许下载的控件运行。这种方法类似于ActiveX的安全性设置，但是比之在设置权限更加详细和强大。同JAVA APPLET的沙箱安全机制相比，.NET 的客户端控件可以在本地简单设置后访问客户端的各种资源。由于这一方面的用途不是我们的重点，所以我们在这里就不再更详细的讨论其用途及其实现原理了。
下面我们就谈谈如何应用这一安全特性来解决ASP.NET中存在的系统安全漏洞。由于我们介绍的系统是共享主机，所以有其特殊性，即系统管理员无法事先给所有的代码赋予相应的权限，因为每个用户都可能有各种权限要求，并且这些要求特殊权力的代码在使用中都可能出现的，所以在权限管理上随时都有各种要求。
因此在权限设置方面，不仅仅是管理员设置，也包括了各个共享主机用户的权限请求，这也正是安全代码机制的一个重要部分。
请求权限是您让运行库知道代码执行有哪些操作权限的方法。通过将属性（声明式语法）放到代码的程序级范围来为程序集请求权限。
请求内置权限的代码示例：
//The attribute is placed on the assembly level.
using System.Security.Permissions;
[assembly:PermissionSetAttribute(SecurityAction.RequestMinimum, Name = "FullTrust")]
将此段代码放在程序的开始部分（namespace声明之前），在编译时就会将请求的权限存储在程序集清单中。加载时，运行库检查权限请求，并应用安全策略规则来确定授予程序集哪些权限。
虽然我们编写的大部分代码都没有请求权限，其实不管是共享主机形式还是独立服务器形式都应该请求权限，这是因为请求权限有助于确保只将代码需要的权限授予代码。如果没有授予代码额外权限，即使某些恶意代码想利用您的代码来进行安全性破坏，它也无法操作没有赋给您自己代码相应权限的额外系统资源。您只应该请求代码需要的那些权限，而不应请求更多权限。
代码请求权限之后，系统管理员可以使用"权限查看"工具 (Permview.exe，位于您的.NET Framework的目录的bin目录下) 来检查您的程序集并根据其他条件来设置安全策略以决定是否给您的代码所请求的相应权限。如果您不显式地在代码中请求应用程序需要的权限，那么管理员将很难管理您的应用程序。在权限管理严格的主机上，将无法实现您的代码所要求的功能。
请求权限会通知运行库应用程序正常运行需要哪些权限，或具体不需要哪些权限。在.NET Framework安装后的默认状态下，所有代码都是FullTrust（完全信任）的。这时是不需要申请任何权限的，但是管理员一旦修改了代码安全，我们使用的磁盘访问就要受到限制了，这是就需要申请相应的权限了。我们上边介绍的文件管理代码就需要具有本地硬盘读写操作的能力，则应用程序必须拥有 FileIOPermission。如果代码不请求 FileIOPermission，在本地安全设置不允许应用程序拥有此权限的主机上，在应用程序尝试磁盘操作时就会引发安全性异常。即使应用程序能够处理此异常，也不会允许它操作磁盘。当然，如果您的代码不访问受保护的资源或执行受保护的操作，则不必请求任何权限。例如，如果代码只根据向它传递的输入来计算结果而不使用任何资源，则不必请求权限。如果您的代码访问受保护的资源但未请求必要的权限，则仍可能允许它执行，但如果它尝试访问某种资源而它又没有必要的权限，则可能在执行过程中失败。
现在绝大多数的虚拟主机都禁用了 ASP 的标准组件：FileSystemObject，因为这个组件为 ASP 提供了强大的文件系统访问能力，可以对服务器硬盘上的任何文件进行读、写、复制、删除、改名等操作（当然，这是指在使用默认设置的 Windows NT / 2000 下才能做到）。但是禁止此组件后，引起的后果就是所有利用这个组件的 ASP 将无法运行，无法满足客户的需求。
如何既允许 FileSystemObject 组件，又不影响服务器的安全性（即：不同虚拟主机用户之间不能使用该组件读写别人的文件）呢？这里介绍本人在实验中获得的一种方法，下文以 Windows 2000 Server 为例来说明。
在服务器上打开资源管理器，用鼠标右键点击各个硬盘分区或卷的盘符，在弹出菜单中选择“属性”，选择“安全”选项卡，此时就可以看到有哪些帐号可以访问这个分区（卷）及访问权限。默认安装后，出现的是“Everyone”具有完全控制的权限。点“添加”，将“Administrators”、“Backup Operators”、“Power Users”、“Users”等几个组添加进去，并给予“完全控制”或相应的权限，注意，不要给“Guests”组、“IUSR_机器名”这几个帐号任何权限。然后将“Everyone”组从列表中删除，这样，就只有授权的组和用户才能访问此硬盘分区了，而 ASP 执行时，是以“IUSR_机器名”的身份访问硬盘的，这里没给该用户帐号权限，ASP 也就不能读写硬盘上的文件了。
下面要做的就是给每个虚拟主机用户设置一个单独的用户帐号，然后再给每个帐号分配一个允许其完全控制的目录。
如下图所示，打开“计算机管理”→“本地用户和组”→“用户”，在右栏中点击鼠标右键，在弹出的菜单中选择“新用户”：
在弹出的“新用户”对话框中根据实际需要输入“用户名”、“全名”、“描述”、“密码”、“确认密码”，并将“用户下次登录时须更改密码”前的对号去掉，选中“用户不能更改密码”和“密码永不过期”。本例是给第一虚拟主机的用户建立一个匿名访问 Internet 信息服务的内置帐号“IUSR_VHOST1”，即：所有客户端使用 http://xxx.xxx.xxxx/ 访问此虚拟主机时，都是以这个身份来访问的。输入完成后点“创建”即可。可以根据实际需要，创建多个用户，创建完毕后点“关闭”：
现在新建立的用户已经出现在帐号列表中了，在列表中双击该帐号，以便进一步进行设置：
在弹出的“IUSR_VHOST1”（即刚才创建的新帐号）属性对话框中点“隶属于”选项卡：
刚建立的帐号默认是属于“Users”组，选中该组，点“删除”：
现在出现的是如下图所示，此时再点“添加”：
在弹出的“选择 组”对话框中找到“Guests”，点“添加”，此组就会出现在下方的文本框中，然后点“确定”：
出现的就是如下图所示的内容，点“确定”关闭此对话框：
打开“Internet 信息服务”，开始对虚拟主机进行设置，本例中的以对“第一虚拟主机”设置为例进行说明，右击该主机名，在弹出的菜单中选择“属性”：
弹出一个“第一虚拟主机 属性”的对话框，从对话框中可以看到该虚拟主机用户的使用的是“F:\VHOST1”这个文件夹：
暂时先不管刚才的“第一虚拟主机 属性”对话框，切换到“资源管理器”，找到“F:\VHOST1”这个文件夹，右击，选“属性”→“安全”选项卡，此时可以看到该文件夹的默认安全设置是“Everyone”完全控制（视不同情况显示的内容不完全一样），首先将最将下的“允许将来自父系的可继承权限传播给该对象”前面的对号去掉：
此时会弹出如下图所示的“安全”警告，点“删除”：
此时安全选项卡中的所有组和用户都将被清空（如果没有清空，请使用“删除”将其清空），然后点“添加”按钮。
将如图中所示的“Administrator”及在前面所创建的新帐号“IUSR_VHOST1”添加进来，将给予完全控制的权限，还可以根据实际需要添加其他组或用户，但一定不要将“Guests”组、“IUSR_机器名”这些匿名访问的帐号添加上去！
再切换到前面打开的“第一虚拟主机 属性”的对话框，打开“目录安全性”选项卡，点匿名访问和验证控制的“编辑”：
在弹出的“验证方法”对方框（如下图所示），点“编辑”：
弹出了“匿名用户帐号”，默认的就是“IUSR_机器名”，点“浏览”：
在“选择 用户”对话框中找到前面创建的新帐号“IUSR_VHOST1”，双击：
此时匿名用户名就改过来了，在密码框中输入前面创建时，为该帐号设置的密码：
再确定一遍密码：
OK，完成了，点确定关闭这些对话框。
经此设置后，“第一虚拟主机”的用户，使用 ASP 的 FileSystemObject 组件也只能访问自己的目录：F:\VHOST1 下的内容，当试图访问其他内容时，会出现诸如“没有权限”、“硬盘未准备好”、“500 服务器内部错误”等出错提示了。
另：如果该用户需要读取硬盘的分区容量及硬盘的序列号，那这样的设置将使其无法读取。如果要允许其读取这些和整个分区有关的内容，请右键点击该硬盘的分区（卷），选择“属性”→“安全”，将这个用户的帐号添加到列表中，并至少给予“读取”权限。由于该卷下的子目录都已经设置为“禁止将来自父系的可继承权限传播给该对象”，所以不会影响下面的子目录的权限设置。
此方法可以从根本上杜绝FSO的虚拟主机问题，昨天晚上我也试用了这一方法很方便的解决了FSO的问题。
在Microsoft .NET Framework Configuration中可以设置所有关于.NET Framework的属性。
点击我的电脑，打开下拉菜单，我们可以看到程序集缓存、已配置程序集、远程处理服务、运行库安全策略、应用程序等五项。运行库安全策略设置是我们这篇文章的重点。
我们可以先查看一下程序集缓存，在这里我们可以看到所有的全局程序集缓存，全局程序集缓存中存储了专门指定给由计算机中若干应用程序共享的程序集。在这里我们可以发现我们可以使用的所有的程序集，同时也可以添加和删除某些程序集。详细操作请参见.NET Framework SDK文档。
我们在这里主要讨论的是运行库安全策略。在此策略中，按层次结构由高到低分为四个级别，即：企业、计算机、用户、应用程序。在计算权限授予时，运行库从该层次结构的顶部开始，然后向下进行计算。较低的策略级别不能对在较高级别上授予的权限进行增加，但是可以使权限减少。这就是说如果我们将计算机策略设置为较小的权限时，可以不必更改企业策略就可以使设置的权限生效，也就是说权限检查的顺序是从低级别到高级别，只有在低级别中不存在的设置才会检查上一级的设置。默认情况下，用户策略和应用程序域策略的限制性小于计算机策略和企业级策略。大部分默认策略存在于计算机级别。所以我们需要将默认安装的主机的权限在计算机级别上进行修改，修改的内容根据主机是不是共享主机，主机应用的其他不明代码的可能性来设置。如果是我们讨论的共享主机的话，在计算机级别上就尽量将权限设的小一些，为了避免我们讨论的文件系统安全问题，一定要注意权限中的本地磁盘访问权限。
我们打开计算机策略设置可以发现几个默认的代码组、权限集和策略程序集。
根据需要，我们可以添加代码组和自定义的权限集。
在添加代码组的时候可以选择几种条件，主要的条件类型：默认为All Code、应用程序目录、哈希、强名称、作者、站点等。
对于我们所要讨论的共享主机，我们需要将My_Computer_Zone下的All Code的权限更改为不能进行磁盘读写，在更改之前，我们需要先定义一个权限集。这一权限集的作用就是将我们需要点击权限集，右键快捷菜单中选择新建，会出现一个创建权限集的窗口，这里需要给我们新建的权限集命名。下一步就是将单个权限分配给权限集。如下图所示。
在这里我们可以给这个新建的权限集赋予一个的系统权限，如上图所示，可用的权限包括：目录服务、DNS、事件日志、环境变量、文件IO、OLEDB数据库操作、注册表等等。我们主要要说明的是文件IO操作，其他的权限操作可以根据自己的需求来设置。这里我们就不再说明了。
在文件IO的权限设置中我们可以自定义针对每一个目录的权限，这里包括读、写、追加、路径盘等操作，在这里我们可以将我们需要的目录权限添加到列表中。因为我们是利用这一权限使所有没有配置权限的代码不可以进行文件IO操作，所以我们不强文件IO添加到分配的权限中。
新建了这一权限集后，我们更改一下默认设置，即将All Code的权限设置为此新建的权限集，也就是说所有没有在此定义代码都不能访问文件IO系统。
这里需要注意一件事情，因为Microsoft .NET Framework Configuration本身也需要文件IO权限，如果没有单独分配给Configuration一个文件IO操作权限的话，那么您就不能再次使用Configuration来设置权限了，只能重新安装.NET Framework了。所以我们需要将FullTrust权限分配给Configuration所使用的Dll，即mscorcfg.dll。在添加时，成员条件可以选择强名称，使用"导入",到winnt/window .net/framework/versionnumber/下选择mscorcfg.dll。如果需要运行其他配置程序，还需要设置相应的权限，这些系统程序一般都在系统程序集缓存中。
这样我们就完成了一个简单的设置，可以防止任何未经验证的代码访问文件IO系统。这样就从根本上防止了磁盘恶意操作。
如果您今后需要利用这一功能或者有共享主机用户需要使用文件IO功能，那么您可以在Microsoft .NET Framework Configuration中将其加入代码，如果不能使其使用其他功能，可以仅仅设置一个只具有文件IO权限的权限集。如果是共享主机用户您还可以给他分配直接到其所使用的目录的全部读写权限，对于他的日志文档，您可以将读功能分配给用户。通过上边新建权限集时我们可以发现：权限集可以规定到每一个目录的读写权限，所以可以将用户锁定于其可以使用的目录中。当然对于共享主机提供商来说，最好的方法就是自己实现这些功能，然后配置权限系统使用户使用共享主机提供商的程序来实现他们的正常操作，而避免了恶意文件操作。
需要注意的是如果分配给每一个单独的程序相应的权限时，我们最好使用强名称这一方式或者其他的可验证方式，强名称由程序集的标识--其简单文本名称、版本号和区域性信息（如果提供）--加上公钥和数字签名组成。这就需要我们使用Sn.exe 来设置密钥、签名和签名验证。强名称保证了程序是开发人员开发的并且没有被改动。
在进行上面的设置之后，管理员可以根据用户的各种需求来设置不同的代码集和权限集。
我们已经简单的介绍了一下ASP.NET中关于文件IO系统的漏洞的防治方法，这一方法有些繁琐，但是却可以从根本上杜绝一些漏洞，由于.NET的JIT（运行时编译）和IL（中间语言），.NET可以在程序编译时检查程序的安全性设置，所以能从根本上防止一些非法访问。.NET的代码安全性的内容很全面，我们讨论的只是很少的一部分，更多的功能需要大家共同来探索、学习。
为了解决安全问题，.NET Framework提供了一种称为代码访问安全性的安全机制。代码访问安全性允许根据代码的来源和代码的标识等属性将代码设置为不同级别的信任代码,同时还详细定义了不同级别的对代码的信任，从而可以详细的对代码设置各自的权限而不是将最大权限赋给所有的代码。使用代码访问安全性，可以减小恶意代码或各种错误的代码带来的严重的系统安全性问题的可能性。您可以设置允许代码执行的一组操作，同样可以设置永远不允许代码执行的一组操作。
实现代码访问安全性的基础就是JIT（运行时编译）和IL（中间代码）。所以所有以公共语言运行库为目标的托管代码都会受益于代码访问安全性。非托管代码则无法完全使用代码访问安全性。
下面我们将介绍一下代码访问安全性实现的各种功能：
代码访问安全性是控制代码对受保护资源和操作的访问权限的一种机制。在 .NET Framework中，代码访问安全性执行下列功能：
· 定义权限和权限集，它们表示访问各种系统资源的权限。
· 使管理员能够通过将权限集与代码组关联来配置安全策略。
· 使代码能够请求运行所需权限以及其他一些有用的权限，以及指定代码绝对不能拥有哪些权限。
· 根据代码请求的权限和安全策略允许的操作，向加载的每个程序集授予权限。
· 使代码能够要求其调用方拥有特定的权限。
· 使代码能够要求其调用方拥有数字签名，从而只允许特定组织或特定站点的调用方来调用受保护的代码。
· 通过将调用堆栈上每个调用方所授予的权限与调用方必须拥有的权限相比较，加强运行时对代码的限制。
为了确定是否已授予代码相应的权限，.NET运行库的安全系统将遍历整个调用堆栈，将每个调用方所授予的权限与目前要求的权限相比较。如果调用堆栈中的任何调用方没有要求的权限，则会引发安全性异常，并会拒绝访问和相应的操作。堆栈步旨在防止引诱攻击；在这种攻击中，受信程度较低的代码调用高度信任的代码，并使用高度信任的代码执行未经授权的操作。在运行时要求所有调用方都拥有权限将影响性能，但对防止代码遭受攻击至关重要。若要优化性能，可以使代码执行较少的堆栈步；但是，任何时候这样做时均必须确保不会暴露安全缺陷。
还存在另外一种代码访问安全性的常见用途，即应用程序将控件从网络 Web 站点直接下载到客户端，这种方式的代码安全性也是可以在客户端进行设置的，根据签名等数据权限证书来确定是不是可以允许下载的控件运行。这种方法类似于ActiveX的安全性设置，但是比之在设置权限更加详细和强大。同JAVA APPLET的沙箱安全机制相比，.NET 的客户端控件可以在本地简单设置后访问客户端的各种资源。由于这一方面的用途不是我们的重点，所以我们在这里就不再更详细的讨论其用途及其实现原理了。
下面我们就谈谈如何应用这一安全特性来解决ASP.NET中存在的系统安全漏洞。由于我们介绍的系统是共享主机，所以有其特殊性，即系统管理员无法事先给所有的代码赋予相应的权限，因为每个用户都可能有各种权限要求，并且这些要求特殊权力的代码在使用中都可能出现的，所以在权限管理上随时都有各种要求。
因此在权限设置方面，不仅仅是管理员设置，也包括了各个共享主机用户的权限请求，这也正是安全代码机制的一个重要部分。
请求权限是您让运行库知道代码执行有哪些操作权限的方法。通过将属性（声明式语法）放到代码的程序级范围来为程序集请求权限。
请求内置权限的代码示例：
//The attribute is placed on the assembly level.
using System.Security.Permissions;
[assembly:PermissionSetAttribute(SecurityAction.RequestMinimum, Name = "FullTrust")]
将此段代码放在程序的开始部分（namespace声明之前），在编译时就会将请求的权限存储在程序集清单中。加载时，运行库检查权限请求，并应用安全策略规则来确定授予程序集哪些权限。
虽然我们编写的大部分代码都没有请求权限，其实不管是共享主机形式还是独立服务器形式都应该请求权限，这是因为请求权限有助于确保只将代码需要的权限授予代码。如果没有授予代码额外权限，即使某些恶意代码想利用您的代码来进行安全性破坏，它也无法操作没有赋给您自己代码相应权限的额外系统资源。您只应该请求代码需要的那些权限，而不应请求更多权限。
代码请求权限之后，系统管理员可以使用"权限查看"工具 (Permview.exe，位于您的.NET Framework的目录的bin目录下) 来检查您的程序集并根据其他条件来设置安全策略以决定是否给您的代码所请求的相应权限。如果您不显式地在代码中请求应用程序需要的权限，那么管理员将很难管理您的应用程序。在权限管理严格的主机上，将无法实现您的代码所要求的功能。
请求权限会通知运行库应用程序正常运行需要哪些权限，或具体不需要哪些权限。在.NET Framework安装后的默认状态下，所有代码都是FullTrust（完全信任）的。这时是不需要申请任何权限的，但是管理员一旦修改了代码安全，我们使用的磁盘访问就要受到限制了，这是就需要申请相应的权限了。我们上边介绍的文件管理代码就需要具有本地硬盘读写操作的能力，则应用程序必须拥有 FileIOPermission。如果代码不请求 FileIOPermission，在本地安全设置不允许应用程序拥有此权限的主机上，在应用程序尝试磁盘操作时就会引发安全性异常。即使应用程序能够处理此异常，也不会允许它操作磁盘。当然，如果您的代码不访问受保护的资源或执行受保护的操作，则不必请求任何权限。例如，如果代码只根据向它传递的输入来计算结果而不使用任何资源，则不必请求权限。如果您的代码访问受保护的资源但未请求必要的权限，则仍可能允许它执行，但如果它尝试访问某种资源而它又没有必要的权限，则可能在执行过程中失败。
现在绝大多数的虚拟主机都禁用了 ASP 的标准组件：FileSystemObject，因为这个组件为 ASP 提供了强大的文件系统访问能力，可以对服务器硬盘上的任何文件进行读、写、复制、删除、改名等操作（当然，这是指在使用默认设置的 Windows NT / 2000 下才能做到）。但是禁止此组件后，引起的后果就是所有利用这个组件的 ASP 将无法运行，无法满足客户的需求。
如何既允许 FileSystemObject 组件，又不影响服务器的安全性（即：不同虚拟主机用户之间不能使用该组件读写别人的文件）呢？这里介绍本人在实验中获得的一种方法，下文以 Windows 2000 Server 为例来说明。
在服务器上打开资源管理器，用鼠标右键点击各个硬盘分区或卷的盘符，在弹出菜单中选择“属性”，选择“安全”选项卡，此时就可以看到有哪些帐号可以访问这个分区（卷）及访问权限。默认安装后，出现的是“Everyone”具有完全控制的权限。点“添加”，将“Administrators”、“Backup Operators”、“Power Users”、“Users”等几个组添加进去，并给予“完全控制”或相应的权限，注意，不要给“Guests”组、“IUSR_机器名”这几个帐号任何权限。然后将“Everyone”组从列表中删除，这样，就只有授权的组和用户才能访问此硬盘分区了，而 ASP 执行时，是以“IUSR_机器名”的身份访问硬盘的，这里没给该用户帐号权限，ASP 也就不能读写硬盘上的文件了。
下面要做的就是给每个虚拟主机用户设置一个单独的用户帐号，然后再给每个帐号分配一个允许其完全控制的目录。
如下图所示，打开“计算机管理”→“本地用户和组”→“用户”，在右栏中点击鼠标右键，在弹出的菜单中选择“新用户”：
在弹出的“新用户”对话框中根据实际需要输入“用户名”、“全名”、“描述”、“密码”、“确认密码”，并将“用户下次登录时须更改密码”前的对号去掉，选中“用户不能更改密码”和“密码永不过期”。本例是给第一虚拟主机的用户建立一个匿名访问 Internet 信息服务的内置帐号“IUSR_VHOST1”，即：所有客户端使用 http://xxx.xxx.xxxx/ 访问此虚拟主机时，都是以这个身份来访问的。输入完成后点“创建”即可。可以根据实际需要，创建多个用户，创建完毕后点“关闭”：
现在新建立的用户已经出现在帐号列表中了，在列表中双击该帐号，以便进一步进行设置：
在弹出的“IUSR_VHOST1”（即刚才创建的新帐号）属性对话框中点“隶属于”选项卡：
刚建立的帐号默认是属于“Users”组，选中该组，点“删除”：
现在出现的是如下图所示，此时再点“添加”：
在弹出的“选择 组”对话框中找到“Guests”，点“添加”，此组就会出现在下方的文本框中，然后点“确定”：
出现的就是如下图所示的内容，点“确定”关闭此对话框：
打开“Internet 信息服务”，开始对虚拟主机进行设置，本例中的以对“第一虚拟主机”设置为例进行说明，右击该主机名，在弹出的菜单中选择“属性”：
弹出一个“第一虚拟主机 属性”的对话框，从对话框中可以看到该虚拟主机用户的使用的是“F:\VHOST1”这个文件夹：
暂时先不管刚才的“第一虚拟主机 属性”对话框，切换到“资源管理器”，找到“F:\VHOST1”这个文件夹，右击，选“属性”→“安全”选项卡，此时可以看到该文件夹的默认安全设置是“Everyone”完全控制（视不同情况显示的内容不完全一样），首先将最将下的“允许将来自父系的可继承权限传播给该对象”前面的对号去掉：
此时会弹出如下图所示的“安全”警告，点“删除”：
此时安全选项卡中的所有组和用户都将被清空（如果没有清空，请使用“删除”将其清空），然后点“添加”按钮。
将如图中所示的“Administrator”及在前面所创建的新帐号“IUSR_VHOST1”添加进来，将给予完全控制的权限，还可以根据实际需要添加其他组或用户，但一定不要将“Guests”组、“IUSR_机器名”这些匿名访问的帐号添加上去！
再切换到前面打开的“第一虚拟主机 属性”的对话框，打开“目录安全性”选项卡，点匿名访问和验证控制的“编辑”：
在弹出的“验证方法”对方框（如下图所示），点“编辑”：
弹出了“匿名用户帐号”，默认的就是“IUSR_机器名”，点“浏览”：
在“选择 用户”对话框中找到前面创建的新帐号“IUSR_VHOST1”，双击：
此时匿名用户名就改过来了，在密码框中输入前面创建时，为该帐号设置的密码：
再确定一遍密码：
OK，完成了，点确定关闭这些对话框。
经此设置后，“第一虚拟主机”的用户，使用 ASP 的 FileSystemObject 组件也只能访问自己的目录：F:\VHOST1 下的内容，当试图访问其他内容时，会出现诸如“没有权限”、“硬盘未准备好”、“500 服务器内部错误”等出错提示了。
另：如果该用户需要读取硬盘的分区容量及硬盘的序列号，那这样的设置将使其无法读取。如果要允许其读取这些和整个分区有关的内容，请右键点击该硬盘的分区（卷），选择“属性”→“安全”，将这个用户的帐号添加到列表中，并至少给予“读取”权限。由于该卷下的子目录都已经设置为“禁止将来自父系的可继承权限传播给该对象”，所以不会影响下面的子目录的权限设置。
此方法可以从根本上杜绝FSO的虚拟主机问题，昨天晚上我也试用了这一方法很方便的解决了FSO的问题。
在Microsoft .NET Framework Configuration中可以设置所有关于.NET Framework的属性。
点击我的电脑，打开下拉菜单，我们可以看到程序集缓存、已配置程序集、远程处理服务、运行库安全策略、应用程序等五项。运行库安全策略设置是我们这篇文章的重点。
我们可以先查看一下程序集缓存，在这里我们可以看到所有的全局程序集缓存，全局程序集缓存中存储了专门指定给由计算机中若干应用程序共享的程序集。在这里我们可以发现我们可以使用的所有的程序集，同时也可以添加和删除某些程序集。详细操作请参见.NET Framework SDK文档。
我们在这里主要讨论的是运行库安全策略。在此策略中，按层次结构由高到低分为四个级别，即：企业、计算机、用户、应用程序。在计算权限授予时，运行库从该层次结构的顶部开始，然后向下进行计算。较低的策略级别不能对在较高级别上授予的权限进行增加，但是可以使权限减少。这就是说如果我们将计算机策略设置为较小的权限时，可以不必更改企业策略就可以使设置的权限生效，也就是说权限检查的顺序是从低级别到高级别，只有在低级别中不存在的设置才会检查上一级的设置。默认情况下，用户策略和应用程序域策略的限制性小于计算机策略和企业级策略。大部分默认策略存在于计算机级别。所以我们需要将默认安装的主机的权限在计算机级别上进行修改，修改的内容根据主机是不是共享主机，主机应用的其他不明代码的可能性来设置。如果是我们讨论的共享主机的话，在计算机级别上就尽量将权限设的小一些，为了避免我们讨论的文件系统安全问题，一定要注意权限中的本地磁盘访问权限。
我们打开计算机策略设置可以发现几个默认的代码组、权限集和策略程序集。
根据需要，我们可以添加代码组和自定义的权限集。
在添加代码组的时候可以选择几种条件，主要的条件类型：默认为All Code、应用程序目录、哈希、强名称、作者、站点等。
对于我们所要讨论的共享主机，我们需要将My_Computer_Zone下的All Code的权限更改为不能进行磁盘读写，在更改之前，我们需要先定义一个权限集。这一权限集的作用就是将我们需要点击权限集，右键快捷菜单中选择新建，会出现一个创建权限集的窗口，这里需要给我们新建的权限集命名。下一步就是将单个权限分配给权限集。如下图所示。
在这里我们可以给这个新建的权限集赋予一个的系统权限，如上图所示，可用的权限包括：目录服务、DNS、事件日志、环境变量、文件IO、OLEDB数据库操作、注册表等等。我们主要要说明的是文件IO操作，其他的权限操作可以根据自己的需求来设置。这里我们就不再说明了。
在文件IO的权限设置中我们可以自定义针对每一个目录的权限，这里包括读、写、追加、路径盘等操作，在这里我们可以将我们需要的目录权限添加到列表中。因为我们是利用这一权限使所有没有配置权限的代码不可以进行文件IO操作，所以我们不强文件IO添加到分配的权限中。
新建了这一权限集后，我们更改一下默认设置，即将All Code的权限设置为此新建的权限集，也就是说所有没有在此定义代码都不能访问文件IO系统。
这里需要注意一件事情，因为Microsoft .NET Framework Configuration本身也需要文件IO权限，如果没有单独分配给Configuration一个文件IO操作权限的话，那么您就不能再次使用Configuration来设置权限了，只能重新安装.NET Framework了。所以我们需要将FullTrust权限分配给Configuration所使用的Dll，即mscorcfg.dll。在添加时，成员条件可以选择强名称，使用"导入",到winnt/window .net/framework/versionnumber/下选择mscorcfg.dll。如果需要运行其他配置程序，还需要设置相应的权限，这些系统程序一般都在系统程序集缓存中。
这样我们就完成了一个简单的设置，可以防止任何未经验证的代码访问文件IO系统。这样就从根本上防止了磁盘恶意操作。
如果您今后需要利用这一功能或者有共享主机用户需要使用文件IO功能，那么您可以在Microsoft .NET Framework Configuration中将其加入代码，如果不能使其使用其他功能，可以仅仅设置一个只具有文件IO权限的权限集。如果是共享主机用户您还可以给他分配直接到其所使用的目录的全部读写权限，对于他的日志文档，您可以将读功能分配给用户。通过上边新建权限集时我们可以发现：权限集可以规定到每一个目录的读写权限，所以可以将用户锁定于其可以使用的目录中。当然对于共享主机提供商来说，最好的方法就是自己实现这些功能，然后配置权限系统使用户使用共享主机提供商的程序来实现他们的正常操作，而避免了恶意文件操作。
需要注意的是如果分配给每一个单独的程序相应的权限时，我们最好使用强名称这一方式或者其他的可验证方式，强名称由程序集的标识--其简单文本名称、版本号和区域性信息（如果提供）--加上公钥和数字签名组成。这就需要我们使用Sn.exe 来设置密钥、签名和签名验证。强名称保证了程序是开发人员开发的并且没有被改动。
在进行上面的设置之后，管理员可以根据用户的各种需求来设置不同的代码集和权限集。
我们已经简单的介绍了一下ASP.NET中关于文件IO系统的漏洞的防治方法，这一方法有些繁琐，但是却可以从根本上杜绝一些漏洞，由于.NET的JIT（运行时编译）和IL（中间语言），.NET可以在程序编译时检查程序的安全性设置，所以能从根本上防止一些非法访问。.NET的代码安全性的内容很全面，我们讨论的只是很少的一部分，更多的功能需要大家共同来探索、学习。
