● 如何构建和配置更加安全的Web站点（1） - 荔园在线 | 深圳大学学生论坛,荔园晨风BBS,深大在线网站

荔园之美，在春之萌芽，在夏之绽放，在秋之收获，在冬之沉淀

发信人: hellsolaris (qq), 信区: Security
标题: 如何构建和配置更加安全的Web站点（1）
发信站: 荔园晨风BBS站 (Wed Dec 3 14:10:59 2003)

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

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

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

Microsoft 使用 Microsoft® .NET Framework 开发其应用程序。Microsoft® .N
ET Framework 是一个完整的 Windows 组件，支持构建和运行下一代应用程序和 XML Web
Service。此应用程序以 Microsoft® Internet 信息服务 (IIS) 5.0 为宿主，并使
用 Microsoft® SQL Server™ 2000 作为其数据库。所有服务器都运行在 Micr
osoft® 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 多次攻击。正如它在第一届和第二届 OpenH
ack 竞赛中表现的一样，Microsoft 安然无恙地从 OpenHack 4 竞赛中胜出。本文将对竞
赛中使用的各种技术加以介绍，以说明此解决方案的构建和配置方法，并向确保自己的解
决方案安全性的开发人员和系统管理员介绍如何应用这些最佳方案。

Web 应用程序

此应用程序本身模拟 eWeek eXcellence Awards Web 站点。在此站点中，用户可以登记其
公司的产品或服务以参与获奖评选。用户可以设置一个帐户，以输入产品或服务进行评选
，可以提交信用卡号支付报名费，还可以获取有关奖项本身的信息。Microsoft 使用 .NE
T Framework 构建其解决方案，.NET Framework 是一个完整的 Windows 组件，用于构建
和运行应用程序及 XML Web Service。大多数开发均围绕 Framework 的 ASP.NET、ADO.N
ET 和加密类库进行，这三项技术提供的功能分别用于构建基于 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 文件的部分添加了以下几行代码，以请求
基于窗体的身份验证并指定登录页的位置。

<authentication mode="Forms">
<forms loginUrl="Login.aspx" name="OPSAMPLEAPP"/>
</authentication>

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

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>

<authorization>
<deny users="?" />
</authorization>
</system.web>
</configuration>

通过这种方式使用这两个 .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 类和 RequiredFieldVa
lidator 类）提供的有效性验证控制，可确保提供了所需的所有输入，且均为有效数据。
只允许使用用于提供所需用户操作的字符，在本例中，字符范围很有限。例如，某些字段
只允许输入“[ ,\.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.HttpServerUtilit
y 类中的 HtmlEncode 方法即可实现，如下所示。

SomeLabel.Text = Server.HtmlEncode(username);

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

存储机密信息

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

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

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

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

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

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

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

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

Internet 信息服务 (IIS) 5.0

为了防止攻击者攻击 Web 服务器本身，我们对 Windows 2000 Advanced Server 中的 In
ternet 信息服务 (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 A
SP.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 锁定工具中免费提供了 URLSca
n。与前面提到的 IIS 锁定工具一样，URLScan 是一种很出色的资源，所有运行 IIS 的系
统管理员都应该使用它。

--

※ 来源:．荔园晨风BBS站 http://bbs.szu.edu.cn [FROM: 61.144.235.41]

荔园在线首页友情链接：深圳大学深大招生荔园晨风BBS S-Term软件网络书店