处理 SSI 文件时出错
公告：
说明：本文中所需环境为2003Server+iis6.0+ms sql2000
曾经很早就在网上看到一篇关于＜asp.net虚拟主机的重大隐患＞的文章，当时并不在意，做过asp虚拟主机的朋友可能都知道，即对每一个用户都设置一个独立的服务器用户和单个目录的操作权限，能够基本上解决asp的fso问题。
在网上无意中发现了一个叫做webadmin的asp.net-webshell，对自己的服务器进行测试的时候，让我大吃一惊，居然对我服务器的c盘有读取的权限。以及对整个硬盘的修改删除权限。这样的话，那么我的服务器的安全……
为了进一步证实，本人曾在国内一些著名的虚拟主机提供商上作过测试，均有和我一样的问题。
有必要先介绍一下漏洞的原因。
ASP中常用的标准组件：FileSystemObject，这个组件为 ASP 提供了强大的文件系统访问能力，可以对服务器硬盘上的任何有权限的目录和文件进行读写、删除、改名等操作。FSO对象来自微软提供的脚本运行库scrrun.dll中。
在ASP.NET中我们发现这一问题仍然存在，并且变得更加难以解决。这是因为.NET中关于系统IO操作的功能变得更加强大，而使这一问题更严重的是ASP.NET所具有的一项新功能，这就组件不需要象ASP那样必须要使用regsvr32来注册了，只需将Dll类库文件上传到bin目录下就可以直接使用了。这一功能确实给开发ASP.NET带来了很大的方便，但是却使我们在ASP中将此dll删除或者改名的解决方法失去效用了，防范此问题就变得更加复杂。需要进一步了解的朋友可以看＜asp.net虚拟主机的重大隐患＞一文，本文就不再重复。只针对此问题引出虚拟主机的安全设置。
网上提出针对此问题用Microsoft .NET Framework Configration设置System.io的对目录读取的权限，经过我们长时间的测试没有成功，可能是.net framework1.1机制改革了？
废话不说。先说说解决的思路：在 IIS 6 中，Web 应用程序的工作进程设置为以进程标识“Network Service”运行。在 IIS 5 中，进程外 Web 应用程序则设置为以 IWAM_＜服务器名＞ 帐户运行，这个帐户是普通的本地用户帐户。
Network Service 是 Windows Server 2003 中的内置帐户。了解 IIS 5 上的本地用户帐户（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 中，无需提升权限即可运行 Web 应用程序。这对于 IIS 安全性来说，是一个特大的消息，因为不存在缓冲溢出，怀有恶意的应用程序无法破译进程标识，或是对应用程序的攻击不能进入 System 用户环境。更为重要的一点是，再也不能形成针对 System 帐户的“后门”，例如，再也无法通过 InProcessIsapiApps 元数据库项利用加载到 Inetinfo 的应用程序。
Network Service 帐户在创建时不仅仅考虑了在 IIS 6 中的应用。它还具有进程标识 W3WP.exe 的绝大部分（并不是全部）权限。如同 ASPNET 用户为了运行 ASP.net 应用程序，需要具有 IIS 5 服务器上某些位置的访问权限，进程标识 W3WP.exe 也需要具有类似位置的访问权限，而且还需要一些默认情况下没有指派给内置组的权限。
为了管理的方便，在安装 IIS 6 时创建了 IIS_WPG 组（也称为 IIS 工作进程组，IIS Worker Process Group），而且它的成员包括 Local System（本地系统）、Local Service（本地服务）、Network Service（网络服务）和 IWAM 帐户。IIS_WPG 的成员具有适当的 NTFS 权限和必要的用户权限，可以充当 IIS 6 中工作进程的进程标识。
因此，Network Service 帐户提供了访问上述位置的权限，具有充当 IIS 6 工作进程的进程标识的充足权限，以及具有访问网络的权限。
Msdn上说：在 Windows Server 2003 中，用户上下文称为 NETWORK SERVICE。这些用户帐户是在 .NET Framework 安装过程中创建的，它具有唯一的不易破解的密码，并仅被授予有限的权限。ASPNET 或 NETWORK SERVICE 用户只能访问运行 Web 应用程序所需的特定文件夹，如 Web 应用程序存储已编译文件的 \bin 目录。
要将进程标识设置为特定用户名，以取代 ASPNET 或 NETWORK SERVICE 用户标识，您提供的用户名和密码都必须存储在 machine.config 文件中。
但是根据实际情况，asp.net的system.io可以无限制访问不设防的服务器路径。不知道这算不算一个ms的重大漏洞。而且根本不能使iis以machine.config的用户执行asp.net程序。J
如何解决呢？答案就是—应用程序池。
IIS 6.0 在被称为应用程序隔离模式（隔离模式）的两种不同操作模式下运行，它们是：工作进程隔离模式和 IIS 5.0 隔离模式。这两种模式都要依赖于 HTTP.sys 作为超文本传输协议 (HTTP) 侦听程序；然而，它们内部的工作原理是截然不同的。
工作进程隔离模式利用 IIS 6.0 的重新设计的体系结构并且使用工作进程的核心组件。IIS 5.0 隔离模式用于依赖 IIS 5.0 的特定功能和行为的应用程序。该隔离模式由 IIs5IsolationModeEnabled 配置数据库属性指定。
您所选择的 IIS 应用程序隔离模式对性能、可靠性、安全性和功能可用性都会产生影响。工作进程隔离模式是 IIS 6.0 操作的推荐模式，因为它为应用程序提供了更可靠的平台。工作进程隔离模式也提供了更高级别的安全性，因为运行在工作进程中的应用程序的默认标识为 NetworkService。
以 IIS 5.0 隔离模式运行的应用程序的默认标识为 LocalSystem，该标识允许访问并具有更改计算机上几乎所有资源的能力。
由此可见，我们只能使用工作进程隔离模式解决.net的安全问题。默认情况下，IIS 6.0在工作进程隔离模式下运行，如图五所示。在这种模式中，对于每一个Web应用，IIS 6.0都用一个独立的w3wp.exe的实例来运行它。w3wp.exe也称为工作进程（Worker Process），或W3Core。
可靠性和安全性。可靠性的提高是因为一个Web应用的故障不会影响到其他Web应用，也不会影响http.sys，每一个Web应用由W3SVC单独地监视其健康状况。安全性的提高是由于应用程序不再象IIS 5.0和IIS 4.0的进程内应用那样用System帐户运行，默认情况下，w3wp.exe的所有实例都在一个权限有限的“网络服务”帐户下运行，如图六所示，必要时，还可以将工作进程配置成用其他用户帐户运行。
对，这里，这里就是我们解决的核心。
曾经很早就在网上看到一篇关于＜asp.net虚拟主机的重大隐患＞的文章，当时并不在意，做过asp虚拟主机的朋友可能都知道，即对每一个用户都设置一个独立的服务器用户和单个目录的操作权限，能够基本上解决asp的fso问题。
在网上无意中发现了一个叫做webadmin的asp.net-webshell，对自己的服务器进行测试的时候，让我大吃一惊，居然对我服务器的c盘有读取的权限。以及对整个硬盘的修改删除权限。这样的话，那么我的服务器的安全……
为了进一步证实，本人曾在国内一些著名的虚拟主机提供商上作过测试，均有和我一样的问题。
有必要先介绍一下漏洞的原因。
ASP中常用的标准组件：FileSystemObject，这个组件为 ASP 提供了强大的文件系统访问能力，可以对服务器硬盘上的任何有权限的目录和文件进行读写、删除、改名等操作。FSO对象来自微软提供的脚本运行库scrrun.dll中。
在ASP.NET中我们发现这一问题仍然存在，并且变得更加难以解决。这是因为.NET中关于系统IO操作的功能变得更加强大，而使这一问题更严重的是ASP.NET所具有的一项新功能，这就组件不需要象ASP那样必须要使用regsvr32来注册了，只需将Dll类库文件上传到bin目录下就可以直接使用了。这一功能确实给开发ASP.NET带来了很大的方便，但是却使我们在ASP中将此dll删除或者改名的解决方法失去效用了，防范此问题就变得更加复杂。需要进一步了解的朋友可以看＜asp.net虚拟主机的重大隐患＞一文，本文就不再重复。只针对此问题引出虚拟主机的安全设置。
网上提出针对此问题用Microsoft .NET Framework Configration设置System.io的对目录读取的权限，经过我们长时间的测试没有成功，可能是.net framework1.1机制改革了？
废话不说。先说说解决的思路：在 IIS 6 中，Web 应用程序的工作进程设置为以进程标识“Network Service”运行。在 IIS 5 中，进程外 Web 应用程序则设置为以 IWAM_＜服务器名＞ 帐户运行，这个帐户是普通的本地用户帐户。
Network Service 是 Windows Server 2003 中的内置帐户。了解 IIS 5 上的本地用户帐户（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 中，无需提升权限即可运行 Web 应用程序。这对于 IIS 安全性来说，是一个特大的消息，因为不存在缓冲溢出，怀有恶意的应用程序无法破译进程标识，或是对应用程序的攻击不能进入 System 用户环境。更为重要的一点是，再也不能形成针对 System 帐户的“后门”，例如，再也无法通过 InProcessIsapiApps 元数据库项利用加载到 Inetinfo 的应用程序。
Network Service 帐户在创建时不仅仅考虑了在 IIS 6 中的应用。它还具有进程标识 W3WP.exe 的绝大部分（并不是全部）权限。如同 ASPNET 用户为了运行 ASP.net 应用程序，需要具有 IIS 5 服务器上某些位置的访问权限，进程标识 W3WP.exe 也需要具有类似位置的访问权限，而且还需要一些默认情况下没有指派给内置组的权限。
为了管理的方便，在安装 IIS 6 时创建了 IIS_WPG 组（也称为 IIS 工作进程组，IIS Worker Process Group），而且它的成员包括 Local System（本地系统）、Local Service（本地服务）、Network Service（网络服务）和 IWAM 帐户。IIS_WPG 的成员具有适当的 NTFS 权限和必要的用户权限，可以充当 IIS 6 中工作进程的进程标识。
因此，Network Service 帐户提供了访问上述位置的权限，具有充当 IIS 6 工作进程的进程标识的充足权限，以及具有访问网络的权限。
Msdn上说：在 Windows Server 2003 中，用户上下文称为 NETWORK SERVICE。这些用户帐户是在 .NET Framework 安装过程中创建的，它具有唯一的不易破解的密码，并仅被授予有限的权限。ASPNET 或 NETWORK SERVICE 用户只能访问运行 Web 应用程序所需的特定文件夹，如 Web 应用程序存储已编译文件的 \bin 目录。
要将进程标识设置为特定用户名，以取代 ASPNET 或 NETWORK SERVICE 用户标识，您提供的用户名和密码都必须存储在 machine.config 文件中。
但是根据实际情况，asp.net的system.io可以无限制访问不设防的服务器路径。不知道这算不算一个ms的重大漏洞。而且根本不能使iis以machine.config的用户执行asp.net程序。J
如何解决呢？答案就是—应用程序池。
IIS 6.0 在被称为应用程序隔离模式（隔离模式）的两种不同操作模式下运行，它们是：工作进程隔离模式和 IIS 5.0 隔离模式。这两种模式都要依赖于 HTTP.sys 作为超文本传输协议 (HTTP) 侦听程序；然而，它们内部的工作原理是截然不同的。
工作进程隔离模式利用 IIS 6.0 的重新设计的体系结构并且使用工作进程的核心组件。IIS 5.0 隔离模式用于依赖 IIS 5.0 的特定功能和行为的应用程序。该隔离模式由 IIs5IsolationModeEnabled 配置数据库属性指定。
您所选择的 IIS 应用程序隔离模式对性能、可靠性、安全性和功能可用性都会产生影响。工作进程隔离模式是 IIS 6.0 操作的推荐模式，因为它为应用程序提供了更可靠的平台。工作进程隔离模式也提供了更高级别的安全性，因为运行在工作进程中的应用程序的默认标识为 NetworkService。
以 IIS 5.0 隔离模式运行的应用程序的默认标识为 LocalSystem，该标识允许访问并具有更改计算机上几乎所有资源的能力。
| IIS 功能 | IIS 5.0隔离模式宿主/组件 | 工作进程隔离模式宿主/组件 |
| 工作进程管理 | N/A | Svchost.exe/WWW 服务 |
| 工作进程 | N/A | W3wp.exe/工作进程 |
| 运行进程内ISAPI 扩展 | Inetinfo.exe | W3wp.exe |
| 运行进程外ISAPI 扩展 | DLLHost.exe | N/A（所有的 ISAPI 扩展都在进程内） |
| 运行ISAPI筛选器 | Inetinfo.exe | W3wp.exe |
| HTTP.sys 配置 Svchost.exe/WWW 服务 | Svchost.exe/WWW | 服务 |
| HTTP 协议支持 | Windows内核/HTTP.sys | Windows 内核/HTTP.sys |
| IIS配置数据库 | Inetinfo.exe | Inetinfo.exe |
| FTP | Inetinfo.exe | Inetinfo.exe |
| NNTP | Inetinfo.exe | Inetinfo.exe |
| SMTP | Inetinfo.exe | Inetinfo.exe |
由此可见，我们只能使用工作进程隔离模式解决.net的安全问题。默认情况下，IIS 6.0在工作进程隔离模式下运行，如图五所示。在这种模式中，对于每一个Web应用，IIS 6.0都用一个独立的w3wp.exe的实例来运行它。w3wp.exe也称为工作进程（Worker Process），或W3Core。
 |
可靠性和安全性。可靠性的提高是因为一个Web应用的故障不会影响到其他Web应用，也不会影响http.sys，每一个Web应用由W3SVC单独地监视其健康状况。安全性的提高是由于应用程序不再象IIS 5.0和IIS 4.0的进程内应用那样用System帐户运行，默认情况下，w3wp.exe的所有实例都在一个权限有限的“网络服务”帐户下运行，如图六所示，必要时，还可以将工作进程配置成用其他用户帐户运行。
 |
对，这里，这里就是我们解决的核心。
|
|
|---|
