利用ASP.NET的内置功能抵御Web攻击

ASP.NET 开发人员应当始终坚持的做法

没有任何开发平台,— 包括 ASP.NET在内 — 能够保证一旦采用了该平台，您就能够编写百分百安全的代码。谁要是这么说，一准在撒谎。好消息是，就 ASP.NET 来说，ASP.NET，特别是版本 1.1 和即将发行的版本 2.0，集成了一些便于使用的内置防御屏障。

光是应用所有这些功能并不足以保护 Web 应用程序，使其免受任何可能和可预见的攻击。但是，如果与其他防御技巧和安全策略相结合，内置的 ASP.NET 功能将可以构成一个强大的工具包，有助于确保应用程序在安全的环境中运行。

Web 安全性是各种因素的总和，是一种范围远超单个应用程序的策略的结果，这种策略涉及数据库管理、网路配置，以及社会工程和 phishing。

本文的目的在于说明 ASP.NET 开发人员为了将安全标准保持到合理的高度，所应始终坚持的做法。这也就是安全性最主要的内容:保持警惕，永不完全放松，让坏人越来越难以发起黑客攻击。

下面我们来看看 ASP.NET 提供了哪些可以简化这项工作的功能。

威胁的来源

在表 1 中，我汇总了最常见的 Web 攻击类型，以及应用程序中可能导致这些攻击得手的缺陷。

图1.一次单击攻击

为什么是不抱怀疑的受害者?这是因为，这种情况下，服务器日志中所显示的发出恶意请求的 IP 地址，是该受害者的 IP 地址。如前所述，这种工具并不像“经典”的 XSS 一样常见(和易于发起);但是，它的性质决定了它的后果可能是灾难性。如何应对它?下面，我们审视一下这种攻击在 ASP.NET 环境下的工作机理。

除非操作编码在 Page_Load 事件中，否则 ASP.NET 页根本不可能在回发事件之外执行敏感代码。要使回发事件发生，视图状态域是必需的。请牢记，ASP.NET 会检查请求的回发状态，并根据是否存在 _VIEWSTATE 输入域，相应地设置 IsPostBack。因此，无论谁要向 ASP.NET 页发送虚假请求，都必须提供一个有效的视图状态域。

一次单击攻击要想得手，黑客必须能够访问该页。此时，有远见的黑客会在本地保存该页。这样，他/她就可以访问 _VIEWSTATE 域并使用该域，用旧的视图状态和其他域中的恶意值创建请求。问题是，这能行吗?

为什么不能?如果攻击者可以提供有效的身份验证 cookie，黑客就可以进入，请求将被照常处理。服务器上根本不会检查视图状态内容(当 EnableViewStataMac 为 off 时)，或者只会检查是否被篡改过。默认情况下，试图状态中没有机制可以将该内容与特定的用户关联起来。攻击者可以轻松地重用所获取的视图状态，冒充另一个用户合法地访问该页，以生成虚假请求。这正是 ViewStateUserKey 介入的地方。

如果选择准确，该属性可以将用户特定的信息添加到视图状态。处理请求时，ASP.NET 会从视图状态中提取秘钥，并将其与正在运行的页的 ViewStateUserKey 进行比较。如果两者匹配，请求将被认为是合法的;否则将引发异常。对于该属性，什么值是有效的?

为所有用户将 ViewStateUserKey 设置为常量字符串，相当于将它保留为空。您必须将它设置为对各个用户都不同的值 — 用户 ID，会话 ID 更好些。由于一些技术和社会原因，会话 ID 更为合适，因为会话 ID 不可预测，会超时失效，并且对于每个用户都是不同的。

以下是一些在您的所有页中都必不可少的代码:

void Page_Init (object sender, EventArgs e) { 

ViewStateUserKey = Session.SessionID; 

: 

}

protected override OnInit(EventArgs e) { 

base.OnInit(e); 

ViewStateUserKey = Session.SessionID; 

}

Cookie 和身份验证

Cookie 之所以存在，是因为它们可以帮助开发人员达到一定目的。Cookie 充当了浏览器与服务器之间的一种持续性链接。特别是对于使用单次登录的应用程序来说，失窃的 cookie 正是使得攻击成为可能的罪魁祸首。这对于一次单击攻击来说一点没错。

要使用 Cookie，无需以编程方式显式创建和读取它们。如果您使用会话状态且实现表单身份验证，您会隐式地使用 Cookie。当然，ASP.NET 支持无 cookie 的会话状态，而且，ASP.NET 2.0 还引入了无 cookie 的表单身份验证。因此，理论上您可以在没有 Cookie 的情况下使用这些功能。我并不是说您不再必须这么做了，但事实上这正是疗法比疾病更糟的情形之一。无 Cookie 的会话，实际上将会话 ID 嵌入了 URL 中，这样谁都可以看到。

与使用 Cookie 有关的潜在问题有哪些?Cookie 可能被盗(即被复制到黑客的计算机)和投毒(即被填充以恶意数据)。这些操作通常是即将发起的攻击的前奏。如果被盗，Cookie 会“授权”外部用户以您的名义连接到应用程序(并使用受保护的页)，这可能使黑客轻松地规避授权，并能够执行角色和安全设置所允许受害者执行的任何操作。因此，身份验证 Cookie 通常被赋予相对较短的生存期，即 30 分钟。(请注意，即使浏览器的会话完成所需的时间更长，cookie 仍会过期。)发生失窃时，黑客有 30 分钟的时限来尝试攻击。

可以将这个时限加长，以免用户不得不过于频繁地登录。但请注意，这么做会将您自己置于危险境地。任何情况下，都应避免使用 ASP.NET 持续性 Cookie。它将导致 cookie 具有几乎永久的生存期，最长可达 50 年!下面的代码片段演示了如何轻松修改 cookie 的过期日期。

void OnLogin(object sender, EventArgs e) { 

// Check credentials 

if (ValidateUser(user, pswd)) { 

// Set the cookie's expiration date 

HttpCookie cookie; 

cookie = FormsAuthentication.GetAuthCookie(user, isPersistent); 

if (isPersistent) 

cookie.Expires = DateTime.Now.AddDays(10); 

// Add the cookie to the response 

Response.Cookies.Add(cookie); 

// Redirect 

string targetUrl; 

targetUrl = FormsAuthentication.GetRedirectUrl(user, isPersistent); 

Response.Redirect(targetUrl); 

} 

} 

EnableViewStateMac

视图状态用于在对同一个页的两个连续请求之间保持控件的状态。默认情况下，视图状态是 Base64 编码的，并使用一个哈希值签名，以防止篡改。除非更改默认的页设置，否则不可能篡改视图状态。如果攻击者修改了视图状态，甚至使用正确的算法重新生成了视图状态，ASP.NET 都会捕获这些尝试并引发异常。视图状态被篡改并不一定有害，虽然它修改了服务器控件的状态 — 但可能成为造成严重感染的工具。因此，不 移除默认情况下进行的计算机身份验证代码 (MAC) 交叉检查就异常重要。请参阅图 2。

图 2. 启用 EnableViewStateMac 时,使视图状态本身难以篡改的因素

启用了 MAC 检查时(默认情况)，将对序列化的视图状态附加一个哈希值，该值是使用某些服务器端值和视图状态用户秘钥(如果有)生成的。回发视图状态时，将使用新的服务器端值重新计算该哈希值，并将其与存储的值进行比较。如果两者匹配，则允许请求;否则将引发异常。即使假设黑客具有破解和重新生成视图状态的能力，他/ 她仍需要知道服务器存储的值才可以得出有效的哈希。具体说来，该黑客需要知道 machine.config 的 项中引用的计算机秘钥。

默认情况下， 项是自动生成的，以物理方式存储在 Windows Local Security Authority (LSA) 中。仅在 Web 场(此时视图状态的计算机秘钥必须在所有的计算机上都相同)的情形下，您才应当在 machine.config 文件中将其指定为明文。

视图状态 MAC 检查是通过一个名为 EnableViewStateMac 的 @Page 指令属性控制的。如前所述，默认情况下，它被设置为 true。请永远不要禁用它;否则将会使视图状态篡改一次单击攻击成为可能，并具有很高的成功概率。

ValidateRequest

跨站点脚本 (XSS) 对于很多经验丰富的 Web 开发人员来说是老朋友了，它在 1999 年左右就已经出现了。简单地说，XSS 利用代码中的漏洞来将黑客的可执行代码引入另一个用户的浏览器会话中。如果被执行，注入的代码可以执行多种不同的操作 — 获取 Cookie 并将一个副本上载到黑客控制的 Web 站点，监视用户的 Web 会话并转发数据，修改被黑的页的行为和外观以使其提供错误的信息，甚至使自己变为持续性的，这样用户下一次返回该页时，欺诈代码会再次运行。

代码中的哪些漏洞导致 XSS 攻击成为可能?

XSS 利用的是动态生成 HTML 页、但并不验证回显到页的输入的 Web 应用程序。这里的输入 是指查询字符串、Cookie 和表单域的内容。如果这些内容在未经适当性能检查的情况下出现在网络上，就存在黑客对其进行操作以在客户端浏览器中执行恶意脚本的风险。(前面提到的一次单击攻击其实是 XSS 的一种新近变种。)典型的 XSS 攻击会导致不抱怀疑的用户点击一条诱惑性链接，而该链接中嵌入了转义的脚本代码。欺诈代码将被发送到一个存在漏洞且会毫不怀疑地输出它的页。用户单击一个看上去明显安全的链接，最终导致将一些脚本代码传递到存在漏洞的页，这些代码首先获取用户计算机上的所有 Cookie，然后将它们发送到黑客的 Web 站点。

请务必注意，XSS 不是一个特定于供应商的问题，因此并不一定会利用 Internet Explorer 中的漏洞。它影响目前市场上的所有 Web 服务器和浏览器。更应注意的是，没有哪一个修补程序能够修复这一问题。您完全可以保护自己的页免受 XSS 攻击，方法是应用特定的措施和合理的编码实践。此外，请注意，攻击者并不需要用户单击链接就可以发起攻击。

要防御 XSS，您必须从根本上确定哪些输入是有效的，然后拒绝所有其他输入。

阻止阴险的 XSS 攻击的主要方法是向您的输入(任何类型的输入数据)添加一个设计合理、有效的验证层。例如，某些情况下即使是原本无害的颜色(RGB 三色)也会将不受控制的脚本直接带入页中。

在 ASP.NET 1.1 中，@Page 指令上的 ValidateRequest 属性被打开后，将检查以确定用户没有在查询字符串、Cookie 或表单域中发送有潜在危险性的 HTML 标记。如果检测到这种情况，将引发异常并中止该请求。该属性默认情况下是打开的;您无需进行任何操作就可以得到保护。如果您想允许 HTML 标记通过，必须主动禁用该属性。

ValidateRequest不是万能的药方，无法替代有效的验证层。它基本上通过应用一个正则表达式来捕获一些可能有害的序列。

注 ValidateRequest 功能原本是有缺陷的，因此您需要应用一个修补程序它才能按预期工作。这样的重要信息常常不为人们所注意。奇怪的是，我发现我的其中一台计算机仍受该缺陷的影响。试试看!

没有任何关闭 ValidateRequest 的理由。您可以禁用它，但必须有非常好的理由;其中一条这样的理由可能是用户需要能够将某些 HTML 张贴到站点，以便得到更好的格式设置选项。这种情况下，您应当限制所允许的 HTML 标记的数目，并编写一个正则表达式，以确保不会允许或接受任何其他内容。

以下是一些有助于防止 ASP.NET 遭受 XSS 攻击的其他提示:

1）使用 HttpUtility.HtmlEncode 将危险的符号转换为它们的 HTML 表示形式。

2）使用双引号而不是单引号，这是因为 HTML 编码仅转义双引号。

3）强制一个代码页以限制可以使用的字符数。

总之，使用但是不要完全信任 ValidateRequest 属性，不要太过懒惰。花些时间，从根本上理解 XSS 这样的安全威胁，并规划以一个关键点为中心的防御策略:所有的用户输入都是危险的。

数据库角度

SQL 注入是另一种广为人知的攻击类型，它利用的是使用未筛选的用户输入来形成数据库命令的应用程序。如果应用程序兴高采烈地使用用户键入表单域中的内容来创建 SQL 命令字符串，就会将您暴露在这一风险下:恶意用户只需访问该页并输入欺诈参数，就可以修改查询的性质。您可以在此处了解更多有关 SQL 注入的信息。

要阻止 SQL 注入攻击，有许多方法。以下介绍最常见的技巧。

1）确保用户输入属于适当的类型，并遵循预期的模式(邮政编码、身份证号，电子邮件等)。如果预期来自文本框的数字，请在用户输入无法转换为数字的内容时阻止该请求。

2）使用参数化的查询，使用存储过程更好。

3）使用 SQL Server 权限来限制各个用户可以对数据库执行的操作。例如，您可能需要禁用 xp_cmdshell 或者将该操作的权限仅限于管理员。

如果使用存储过程，可以显著降低发生这种攻击的可能性。实际上，有了存储过程，您就无需动态地撰写 SQL 字符串。此外，SQL Server 中将验证所有参数是否具有指定的类型。虽然光是这些并不是百分百安全的技巧，但是加上验证的话，将足以提高安全性。

更为重要的是，应确保只有经过授权的用户才能够执行可能具有严重后果的操作，如删除表。这要求认真仔细地设计应用程序的中间层。好的技巧(不光是为了安全性)应把焦点集中在角色上。应当将用户分组为各种角色，并为各个角色定义一个包含一组最少的权限的帐户。

几周前，Wintellect Web 站点受到一种很复杂的 SQL 注入的攻击。那位黑客试图创建并启动一个 FTP 脚本来下载一个可能是恶意的可执行程序。幸运的是，这次攻击失败了。或者，其实是强用户验证，使用存储过程和使用 SQL Server 权限，导致了攻击未能成功?

总而言之，您应当遵循这些指南，以避免被注入有害的 SQL 代码:

1）使用尽可能少的权限运行，永远不以“sa”身份执行代码。

2）将访问限制给内置的存储过程。

3）首选使用 SQL 参数化查询。

4）不通过字符串串连来生成语句，不回显数据库错误。

隐藏域

在传统的 ASP 中，隐藏域是唯一一种在请求之间保持数据的方法。您需要在下一个请求中检索的任何数据都被打包到隐藏的域中，并执行回程。如果有人在客户端上修改了该域中存储的值，会怎样?只要文本是明文的，服务器端环境就无法测知这一情况。ASP.NET 中，页和各个控件的 ViewState 属性有两个用途。一方面，ViewState 是跨请求保持状态的方法;另一方面，ViewState 使您能够在受保护的、不易篡改的隐藏域中存储自定义值。

如图2所示，视图状态被附加了一个哈希值，对于每条请求，都会检查该值，以检测是否发生了篡改。除少数几种情况外，没有任何理由要在 ASP.NET 中使用隐藏域。视图状态能够以安全得多的方式实现相同的功能。前面开门见山地讲到过，在明文的隐藏域中存储敏感的值(如价格或信用卡详细信息)，相当于对黑客张开大门;视图状态甚至能够使这种不好的做法比以前更为安全，因为视图状态具有数据保护机制。但是，请牢记，视图状态可以防止篡改，但是并不能保证保密性，除非使用加密 — 存储在视图状态中的信用卡详细信息无论如何都有风险。

在 ASP.NET 中，哪些情况下使用隐藏域是可接受的?当您生成需要将数据发送回服务器的自定义控件时。例如，假定您要创建一个支持重派列顺序的新 DataGrid 控件。您需要在回发中将新的顺序发送回服务器。如果不将这些信息存储到隐藏域中，又可以存储到哪里?

如果隐藏域为读/写域，即预期客户端会写入它，没什么办法能够完全制止黑客攻击。您可以尝试哈希或者加密该文本，但这并不能让您合理地确信不会遭受黑客攻击。此时，最好的防御就是让隐藏域包含惰性和无害的信息。

此外，应当注意 ASP.NET 公开了一个鲜为人知的类，可用于编码和哈希任何序列化的对象.该类为 LosFormatter，ViewState 实现用于创建回程到客户端的编码文本正是同一个类。

电子邮件和垃圾邮件

在本文结尾，请让我指出，最常见的攻击中至少有两种(经典的 XSS 和一次单击)通常是通过诱使不抱怀疑的受害者单击诱惑性和欺骗性的链接来发起的。很多时候我们都可以在自己的收件箱中发现这样的链接，虽然有反垃圾邮件过滤器。几美元就可以买到大量电子邮件地址。用来生成这种列表的其中一种主要的技巧就是扫描 Web 站点上的公共页，查找并获取所有看上去像电子邮件的内容。

如果页上显示了电子邮件地址，很可能或早或晚这个地址都会被自动 Web 程序捕获。真的吗?当然，这要看该电子邮件是如何显示的。如果硬编码它，您输定了。如果采用其他表示形式(如 dino-at-microsoft-dot-com)，是否能够骗过自动 Web 程序不太清楚，但能让所有阅读您的页并想建立合法联系的人光火，倒是一定的。

总体说来，您应当确定一种方法，将电子邮件动态地生成为 mailto 链接。

小结

有人怀疑 Web 可能是所有运行时环境中敌意最盛的吗?根源在于谁都可以访问 Web 站点，并尝试向它传递好的或坏的数据。但是，创建不接受用户输入的 Web 应用程序，又有什么意义呢?

我们还是直面现实吧:无论您的防火墙如何强大，无论您如何频繁地应用可用的修补程序，只要您运行的 Web 应用程序先天包含缺陷，攻击者迟早都可以通过主通道，也就是端口 80，直接进入您的系统的最核心部分。

ASP.NET 应用程序与其他 Web 应用程序相较，既不更易受攻击，也不更安全。安全性和漏洞同样根植于编码实践、实际经验和团队合作。如果网络不安全，那么任何应用程序都不安全;类似地，无论网络如何安全，管理如何精良，如果应用程序存在缺陷，攻击者总是能够得手。

ASP.NET 的好处是提供了一些好的工具，只需少量工作，就可以将安全标准提升到可以接受的级别。当然，这并不是 足够高的级别。不应纯粹以来 ASP.NET 的内置解决方案，同样也不应忽视它们。尽可能多地了解常见的攻击。

（责任编辑：城尘）