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

　　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);

　　}

　　}

　　您可以在自己的登录表单中使用这些代码来微调身份验证 Cookie 的生存期。

　　会话劫持

　　Cookie 还被用于检索特定用户的会话状态。会话的 ID 被存储到 cookie 中，该 cookie 与请求一起来回传送，存储在浏览器的计算机上。同样，如果失窃，会话 cookie 将可被用来使黑客进入系统并访问别人的会话状态。不用说，只要指定的会话处于活动状态(通常不超 20 分钟)，这就有可能发生。通过冒充的会话状态发起的攻击称为会话劫持。

　　这种攻击有多危险?很难讲。这要取决于 Web 站点的功能，更为重要的是，该站点的页是如何设计的。例如，假定您能够获得别人的会话 cookie，并将它附加到对站点上某个页的请求中。您加载该页并逐步研究它的普通用户界面。除了该页使用另一个用户的会话状态工作外，您无法将任何代码注入该页，也无法修改该页中的任何内容。这本身并不太坏，但是如果该会话中的信息是敏感和关键性的，就有可能直接导致黑客成功实现利用。黑客无法渗透到会话存储的内容中，但他可以使用其中存储的信息，就像自己是合法进入的一样。例如，假定有这样一个电子商务应用程序，它的用户在浏览站点时将物品添加到购物车中。

　　方案1 购物车的内容存储在会话状态中。但是，在结帐时，用户被要求通过安全的 SSL 连接确认和输入付款详细信息。这种情况下，通过接入其他用户的会话状态，黑客仅可以了解到一些有关受害者的购物喜好的细节。在这种环境下劫持实际上并不会导致任何损害。受威胁的只是保密性。

　　方案2 应用程序为每位注册用户处理一份档案，并将档案保存在会话状态中。糟糕的是，档案中(可能)包括信用卡信息。为什么要将用户档案详细信息存储到会话中?可能应用程序的其中一个目标是，从根本上避免使用户不得不重复键入自己的信用卡和银行信息。因此，在结算时，应用程序会将用户定位到一个具有预先填充的域的页。而有失谨慎的是，这些域的其中一个是从会话状态中获取的信用卡号。现在您可以猜到故事的结局了吗?

　　应用程序的页的设计，是防止会话劫持攻击的关键所在。当然，还有两点没有理清。第一点是，如何防止 cookie 盗窃?第二点是，ASP.NET 可以如何检测和阻止劫持?

　　ASP.NET 会话 cookie 极其简单，仅限于包含会话 ID 字符串本身。ASP.NET 运行库从 cookie 中提取会话 ID，并将其与活动的会话进行比较。如果 ID 有效，ASP.NET 将连接到对应的会话并继续。这种行为极大地方便了已经偷到或者可以猜出有效的会话 ID 的黑客。

　　XSS 和中间人 (man-in-the-middle) 攻击以及对客户端 PC 的强力访问，都是获取有效 cookie 的方法。为了防止盗窃，您应当实现安全最佳实践来防止 XSS 及其各变种得手。

　　而为了防止会话 ID 猜测，您应当干脆避免太高估计自己的技能。猜测会话 ID 意味着您知道如何预测有效的会话 ID 字符串。对于 ASP.NET 所使用的算法(15 个随机数字，映射为启用 URL 的字符)，随机猜测到有效 ID 的概率接近于零。我想不到任何理由来用自己的会话 ID 生成器替换默认的会话 ID 生成器。许多情况下，这么做只会为攻击者提供方便。

　　会话劫持更为糟糕的后果是一旦 cookie 被盗或者被猜出，ASP.NET 并没有什么办法来检测欺诈性的 cookie 使用。同样，原因是 ASP.NET 将自己限制为检查 ID 的有效性，以及 cookie 的来源地。

　　我在 Wintellect 的朋友 Jeff Prosise 为 MSDN Magazine 写了一篇很好的关于会话劫持的文章。他的结论并不令人安慰:几乎不可能建立能够完全抵御依靠偷来的会话 ID Cookie 所发起的攻击的防御工事。但是他开发的代码为进一步提升安全标准提供了非常明智的建议。Jeff 创建了一个 HTTP 模块，该模块为会话 ID Cookie 监视传入的请求和传出的响应。该模块将一条哈希代码附加到会话 ID 之后，使攻击者重用 cookie 更为困难。

　　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 的内置解决方案，同样也不应忽视它们。尽可能多地了解常见的攻击。