如何构建和配置更加安全的Web站点

　摘要：由 Microsoft 工程师使用 Microsoft .net framework、Microsoft Windows 2000 Advanced Server、Internet 信息服务 5.0 和 Microsoft SQL Server 2000 构建的 Web 站点，在 eWeek OpenHack 4 竞赛中成功顶住了 82,500 多次攻击，并一举胜出。本文介绍此解决方案的构建和配置方法，并为软件开发人员和系统管理员确保自己的解决方案的安全性提供了最佳方案。（本文包含一些指向英文站点的链接。）

简介
Web 应用程序
Internet 信息服务 (IIS) 5.0
Windows 2000 Advanced Server 操作系统
IP 安全标准 (IPSec) 策略
远程管理与监视
SQL Server 2000
密码
小结
更多信息
简介

eWeek Labs 举行了第四届年度 OpenHack 联机安全性竞赛。此次年度竞赛（这是 Microsoft® 第三次参加此项赛事）旨在通过将系统暴露在 Web 真实而险恶的环境中来测试企业的安全性。eWeek 向 Microsoft 和 Oracle 提供了 Web 应用程序示例，要求双方使用各自的技术重新开发此应用程序。随后，eWeek 又邀请美国各地的计算机用户破坏最终站点的安全性，成功者可领取一定数额的奖金。可接受的破坏包括跨站点的脚本攻击、动态 Web 页面源代码泄漏、破坏 Web 页面、向数据库发送恶意 SQL 命令以及窃取所用数据库中的数据。

Microsoft 使用 Microsoft® .NET Framework 开发其应用程序。Microsoft® .NET Framework 是一个完整的 Windows 组件，支持构建和运行下一代应用程序和 XML Web Service。此应用程序以 Microsoft® Internet 信息服务 (IIS) 5.0 为宿主，并使用 Microsoft® SQL Server™ 2000 作为其数据库。所有服务器都运行在 Microsoft® Windows® 2000 Advanced Server 操作系统上。（值得注意的是，如果竞赛时已发布带有 IIS 6.0 的 Microsoft® Windows Server 2003，则当时会使用此版本的操作系统。如果使用 Windows Server 2003，则可以省去竞赛中用于“锁定”操作系统和 Web 服务器的几个步骤。）

竞赛结果可以在 http://www.eweek.com/category2/1,3960,600431,00.asp 中找到。总而言之，Microsoft 的解决方案顶住了 82,500 多次攻击。正如它在第一届和第二届 OpenHack 竞赛中表现的一样，Microsoft 安然无恙地从 OpenHack 4 竞赛中胜出。本文将对竞赛中使用的各种技术加以介绍，以说明此解决方案的构建和配置方法，并向确保自己的解决方案安全性的开发人员和系统管理员介绍如何应用这些最佳方案。

Web 应用程序

此应用程序本身模拟 eWeek eXcellence Awards Web 站点。在此站点中，用户可以登记其公司的产品或服务以参与获奖评选。用户可以设置一个帐户，以输入产品或服务进行评选，可以提交号支付报名费，还可以获取有关奖项本身的信息。Microsoft 使用 .NET Framework 构建其解决方案，.NET Framework 是一个完整的 Windows 组件，用于构建和运行应用程序及 XML Web Service。大多数开发均围绕 Framework 的 ASP.NET、ADO.NET 和加密类库进行，这三项技术提供的功能分别用于构建基于 Web 的应用程序，访问和使用数据，以及加密、解密和确保数据完整性。

窗体身份验证

Microsoft® ASP.NET 类提供了几个用于验证用户身份的选项（即，使用一些凭据，如用户名和密码，来确认给定用户的身份）。这些选项包括集成的 Windows 身份验证、基本身份验证、摘要身份验证、Microsoft® .NET Passport 以及客户证书等。对于每个 eWeek 请求，OpenHack 解决方案选择了基于窗体的或自定义的身份验证。

当用户通过窗体身份验证登录时，系统将创建一个加密的 cookie，用于在整个站点中跟踪用户。（从技术角度而言，cookie 是一个由 Web 站点生成的纯文本字符串，可进入用户的 Web 浏览器内存，用于对浏览站点的用户进行标识。）

如果用户在未登录的情况下请求一个安全页面，系统会将此用户重定向到登录页面，所有这些都只需要使用应用程序的基于 XML 的 Web.config 文件进行配置就可以实现。该文件由 Microsoft® Visual Studio® .NET（用于构建基于 .NET Framework 的应用程序的集成开发环境）自动生成，用于存储 ASP.NET Web 应用程序的配置。

在应用程序的根文件夹中，我们向 Web.config 文件的 部分添加了以下几行代码，以请求基于窗体的身份验证并指定登录页的位置。


 



此顶层配置文件应用到此应用程序的所有页面。然后，用第二个 Web.config 文件创建子目录。此文件只应用到应用程序中的少数几个选定页面，以防未经身份验证的用户（即匿名用户）对其进行访问。第二个 .config 文件继承了顶层 .config 文件的身份验证信息。

 

   
 
     
   
     
   




通过这种方式使用这两个 .config 文件，未经身份验证的用户只能访问主页和其他少数几个页面，而已通过身份验证的用户则还可以访问站点上那些需要用户登录的页面。

登录页本身包含供用户输入用户名和密码的字段，并通过安全套接字层 (SSL) 将其返回给 Web 服务器，从而防止某些用户“窃取”网络中传递的凭据。用户创建新帐户后，Web 应用程序将使用 Triple DES 算法将新密码加密（详见存储机密信息一节的介绍），并将其与用户名一同存储在数据库中。以后登录时，Web 应用程序将使用 Triple DES 对在登录页输入的密码进行加密，然后与数据库中存储的加密密码进行比较。如果这两个密码匹配，Web 应用程序将使用 ASP.NET 库中的 System.Web.Security.FormsAuthentication 类生成一个包含用户的用户名和姓名的加密 cookie。此 cookie 将返回给用户并储存在用户的浏览器中，直到超时为止。用户此后向 Web 站点发送的任何请求都会包含此 cookie。所有涉及 cookie 的传输都使用 SSL 进行，以防“重放”攻击（即攻击者从网络中窃取到 cookie，然后使用它假冒用户进行操作）。强烈建议您通过公共网络发送可用于访问敏感信息的敏感信息或凭据时使用 SSL。

输入有效性验证

OpenHack 在应用程序中实现了不同级别、不同类型的有效性验证，以确保代码以外的输入（即用户输入）无法更改应用程序的操作。验证输入有效性是一个关键的最佳安全方案，有助于防止缓存溢出、跨站点的脚本攻击以及其他潜在的在应用程序上下文中执行恶意代码的尝试。提供多层保护（正如此处所做的）是另一个重要的最佳安全方案，称为“层层设防”。做最坏的打算并假定解决方案的一层或多层可能遭到破坏，这往往很重要。

第一道防线是由 ASP.NET（特别是 RegularExpressionValidator 类和 RequiredFieldValidator 类）提供的有效性验证控制，可确保提供了所需的所有输入，且均为有效数据。只允许使用用于提供所需用户操作的字符，在本例中，字符范围很有限。例如，某些字段只允许输入“[ ',.0-9a-zA-Z_]*”，即空格、单引号、逗号、句号、字母和数字。其他可用于向 Web 站点发送恶意脚本的字符被禁止使用。

除文本框以外，本应用程序还通过“查询字符串”接受某些输入，查询字符串是动态 URL 的一部分，包含用于生成页面的参数。通过 System.Text.RegularExpressions.Regex 类提供的功能，用正则表达式对数据进行验证，如下所示：

Regex isNumber = new Regex("^[0-9]+$");
if(isNumber.Match(inputData) ) {
    // 使用它
}
else {
    // 丢弃它
}


正则表达式是用于匹配文本模式的字符和语法元素集合。在 OpenHack 应用程序中，它们用于确保查询字符串内容是正确且无恶意的。

此应用程序中的所有数据访问均通过参数化存储过程完成，这些存储过程是使用 T-SQL 语言开发的，并且根据定义在数据库内运行。将与数据库的交互限制到存储过程，这通常是一个最佳方案。如果不存在存储过程，则 SQL 查询必须由 Web 应用程序动态构造。如果 Web 层遭到破坏，攻击者就可以向数据库查询中插入恶意命令，以检索、更改或删除数据库中存储的数据。使用存储过程，Web 应用程序与数据库的交互操作仅限于通过存储过程发送的几个特定的严格类型参数。每当开发人员使用 .NET Framework 调用存储过程时，系统都会对发送到此存储过程的参数进行检查，以确保它们是存储过程可接受的类型（如整数、8 个字符的字符串等）。这是 Web 层有效性验证上的又一个保护层，可确保所有输入数据格式正确，而且不能自行构造为可操作的 SQL 语句。

任何数据在返回给用户前均采用 HTML 编码。这只需使用 System.Web.HttpServerUtility 类中的 HtmlEncode 方法即可实现，如下所示。

SomeLabel.Text = Server.HtmlEncode(username);


HTML 编码有助于防止跨站点的脚本攻击。攻击者一旦破坏了数据库，便可向记录中输入脚本，此脚本随后返回给用户并在浏览器中执行。通过 HTML 编码，大多数脚本命令都自动转换为无害文本。

存储机密信息

安全地存储机密信息（如提供数据库登录信息的数据库连接字符串）很重要，这样可以防止攻击者访问并使用这些机密信息来读取、操作数据或重新配置解决方案。由于本解决方案使用了集成的 Windows 身份验证来访问数据库，因此连接字符串的价值对于攻击者来说已经显著降低，这是因为连接字符串只包含服务器的位置和数据库名称，而不包括特定的凭据（如密码）。

默认情况下，Visual Studio .NET 中的数据库连接向导将把连接字符串作为属性值存储在“内含代码”文件（此文件包含应用程序的核心逻辑，这与提供用户界面定义的文件不同）中。

这为开发人员访问字符串提供了方便。但是，如果攻击者设法登录到包含源代码和 .config 文件的物理计算机上，便有可能读取连接字符串并用它来访问数据库以进行恶意破坏。

在生产环境中，通常建议您对连接字符串和任何其他所需的凭据进行妥善地保护。一种保护凭据的方法是 OpenHack 4 中采用的方法：加密连接字符串，将其存储在注册表中，并使用访问控制列表 (ACL) 确保只有系统管理员和 ASPNET 辅助进程（IIS 一节中给出了定义）才能访问注册表项。

使用 Windows 2000/XP 数据保护 API (DPAPI) 函数 CryptProtectData 和 CryptUnprotectData 将数据库连接字符串加密，使用这两个函数可以将机密信息加密，而无需直接管理（或存储）随后用于访问这些机密信息的注册表项。

尽管 DPAPI 非常适合用于加密用户或计算机特定数据，但对于加密存储在共享数据库中的信息（如号码和密码），却不是一种很有效的方法。这是因为 DPAPI 函数根据本地计算机和/或用户信息创建和内部存储加密密钥。在 Web 领域方案中，Web 服务器将使用自己的加密密钥，以防它们访问相同的加密数据。

因此，为了演示 Web 领域方案中使用的方法，生成了一个随机的 Triple DES 加密密钥和初始化向量。此功能是用 .NET Framework 的 System.Security.Cryptography 类中的 TripleDES 类提供的。这些密钥用于对称地加密存储在数据库中的密码和信息。为了存储信息，选择了加密性很强的随机第一块作为处理技术。

生成密钥的备份副本后，我们使用 DPAPI 将其加密并存储到注册表中，然后又使用 ACL 将访问权限仅授予系统管理员和 ASPNET 辅助进程。将密钥加密，可确保当攻击者实际定位并访问数据时，如果不先将密钥解密，便无法解密数据。这是“层层设防”的又一个典型例子。

Internet 信息服务 (IIS) 5.0

为了防止攻击者攻击 Web 服务器本身，我们对 Windows 2000 Advanced Server 中的 Internet 信息服务 (IIS) 5.0 Web 服务器进行了适当的更改。首先，安装了 TechNet Web 站点上列出的所有公用安全性修补程序，以确保拥有最新的增强功能。运行任何软件时，安装最新的 Service Pack 和修补程序是一种非常关键的安全方案。

然后，将磁盘上的默认 Web 站点位置从默认位置 c:inetpub 更改到其他卷。因此，一旦系统在某些方面遭到破坏，攻击者将很难导航到此目录树，除非确实了解此目录树的实际位置，也就是说，攻击者无法通过输入 .. 作为位置说明来轻松地访问 C: 驱动器。

接着，使用静态 Web 服务器附带的模板运行 IIS 锁定工具。此操作删除了此应用程序中未使用的所有其他动态内容类型。以这种方式减少暴露给潜在攻击者的表面区域通常是很重要的最佳方案。可以免费获得 IIS Lockdown Tool。它是一个很出色的资源，所有运行 IIS 的系统管理员都应该使用它。

此时，我们已经安装了 .NET Framework Redistributable（它是运行 .NET Framework 应用程序所必需的）、.NET Framework Service Pack 2、最新的 .NET Framework 问题更正和 MDAC 2.7（.NET Framework 所需的组件）。

在此方案中，应用程序只使用带有 .aspx 扩展名的动态文件和几个用于图像与样式表的静态内容类型。由于不需要 .NET Framework 安装的其他 IIS 应用程序映射，因此将这些扩展重新绑定到 IIS 锁定工具附带的 404.dll 扩展。这样做也是为了减少解决方案暴露的表面区域。

此应用程序使用低权限的默认本地服务帐户（ASPNET 帐户）运行 ASP.NET 代码。“最低权限”原则对于所有管理人员来说都很重要，决不要向帐户授予并非绝对需要的权限。以这种方式锁定解决方案相当于减少暴露的表面区域。

（ASPNET 帐户是在安装 .NET Framework Redistributable 时作为本地帐户创建的，只属于创建该帐户的计算机上的“用户”组。因此它拥有所有与此“用户”组相关的权限，并可与此用户组有权访问的任何资源进行交互。此外，它在默认情况下拥有对 Temporary ASP.NET Files 目录和 %windir%temp 的完全访问权限，以及对 Framework 安装目录的读取权限。）

我们将此 ASPNET 帐户添加到 IIS 锁定工具创建的本地“Web 应用程序组”，以防进程在被偷袭时运行任何未得到授权的命令行可执行程序。

然后，我们修改了此用户组的权限，并允许此用户组中的用户运行应用程序需要的 .NET Framework C# 编译器和资源转换器（Csc.exe 和 Cvtres.exe）。

IIS 锁定工具安装了 URLScan 2.5，它是一个 ISAPI 过滤器，可根据查询长度和字符集等规则监视和过滤发送到 IIS Web 服务器的所有输入请求。将 URLScan 配置成只允许应用程序中使用的扩展集，并用它阻止较长的请求。这是深度防护的另一个示例，它是防止通过用户输入插入恶意代码的额外保护层。TechNet 和 IIS 锁定工具中免费提供了 URLScan。与前面提到的 IIS 锁定工具一样，URLScan 是一种很出色的资源，所有运行 IIS 的系统管理员都应该使用它。

我们为 Web 内容目录设置了适当的权限，从而授予 ASP.NET 进程对内容文件的读访问权限，授予匿名用户对所提供内容的适当只读访问权限。

只有系统帐户和系统管理员组的成员才对 IIS 和 URLScan 的日志目录具有访问权限。限制对日志文件的访问通常很有必要，它使攻击者很难对其进行更改，以覆盖其中的记录或隐藏有关所受攻击的有用信息。

Windows 2000 Advanced Server 操作系统

本次竞赛使用的服务器全部运行安装了 Service Pack 3（它是竞赛时最新的 Service Pack）的 Windows 2000 Advanced Server 操作系统。还安装了自 Service Pack 3 发行以来 TechNet Web 站点上发布的所有安全性修补程序。使用最新的安全性修补程序对系统管理员同样是一个很重要的最佳安全方案。

安装这些更新会对某些配置进行更改，从而进一步增强操作系统级的完整性。首先，禁用了所有不必要的操作系统服务，这通常也是一个最佳方案。通过关闭这些服务，可以释放系统资源并减少暴露给攻击者的表面区域。可以禁用的特定服务将随每个解决方案的需要而变化。Messenger、Alerter 和 ClipBook 只是已禁用服务的几个示例。

强烈建议您阅读 Windows 2000 Server Resource Kit，以帮助确定不需要的服务。然后进行相应的测试，以确保应用程序在没有这些服务的情况下也能正常工作。最后，将这些服务的启动状态更改为 disabled 以关闭它们。

在应用程序中，我们还使用注册表编辑器 (Regedit.exe) 更改了四个注册表设置，以便进一步增强安全性。我们将所有这些都作为最佳方案推荐给您，只要您不需要已禁用的功能即可。

创建注册表项：nolmhash

（需要说明的是，在 Windows 2000 中，这是一个关键字，而在 Windows XP 和 Windows Server 2003 中，这是一个值。）

位置：HKLMSystemCurrentControlSetControlLSA

用途：防止操作系统以 LM 散列格式存储用户密码。此格式只用于不支持 NTLM 或 Kerberos 的 Windows 3.11 客户端。创建和保留此 LM 散列的风险在于，如果攻击者设法将以此格式存储的密码解密，就可以在网络上的其他计算机上重复利用这些密码。

创建注册表值：NoDefaultExempt

位置：HKLMSystemCurrentControlSetServicesIPSEC

用途：默认情况下，IPSec 将允许源端口为 88 的传入通信查询 IPSec 服务，以获取连接到计算机的信息，而不管使用的是哪种 IPSec 策略。通过设置此值，除了我们设置的 IPSec 过滤器允许的通信（详见 IPSec 策略一节的介绍）以外，不允许端口之间进行任何通信。

创建注册表值：DisableIPSourceRouting

位置：HKLMSystemCurrentControlSetServicesTcpipParameters

用途：防止 TCP 数据包显式确定到最终目标的路由，并防止它要求服务器确定最佳路由。这是一个防止“人在中间”攻击（即攻击者通过自己的服务器对数据包进行路由，并在数据包传递期间窃取其中的内容）的保护层。

创建注册表值：SynAttackProtect

位置：HKLMSystemCurrentControlSetServicesTcpipParameters