Web 应用程序的安全性

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 攻击类型，以及应用程序中可能导致这些攻击得手的缺陷。
攻击 攻击的可能发起人
跨站点脚本 (XSS)
回显到页的不可信用户输入
SQL 注入
串连用户输入以形成 SQL 命令
会话劫持
会话 ID 猜测和失窃的会话 ID Cookie
一次单击
通过脚本发送的未被察觉的 HTTP 张贴
隐藏域篡改
未检查（且受信）的隐藏域被填充以敏感数据

表 1. 常见的 Web 攻击
列表中显现出来的关键性事实有哪些？在我看来，起码有以下三点：
? 无论您何时将何种用户输入插入浏览器的标记中，您都潜在地将自己暴露在了代码注入攻击（任何 SQL 注入和 XSS 变种）之下。
? 必须以安全的方式实现数据库访问，就是说，应当为数据库使用尽可能少的权限，并通过角色来划分各个用户的职责。
? 永远都不通过网络发送敏感数据（更别说是明文了），并且必须以安全的方式将敏感数据存储在服务器上。

有意思的是，上面的三点分别针对的是 Web 安全性的三个不同方面，而这三个方面结合起来，才是唯一的一种生成防攻击、防篡改应用程序的合理方式。Web 安全性的各个层面可以总结如下：
? 编码实践：数据验证、类型和缓冲区长度检查，防篡改措施
? 数据访问策略：使用决策来保护可能最弱的帐户，使用存储过程或者至少是参数化的命令。
? 有效的存储和管理：不将关键性数据发送到客户端，使用哈希代码来检测操作，对用户进行身份验证并保护标识，应用严格的密码策略

如您所看到的，只有可以通过开发人员、架构师和管理员的共同努力，才可以产生安全的应用程序。请不要假定您能够以其他方式达到同样目的。
编写 ASP.NET 应用程序时，您并不是独自面对黑客大军：唯一的武器是通过自己的大脑、技能和手指键入的代码行。ASP.NET 1.1 和更高版本都会施加援手，它们具有一些特定的功能，可以自动提高防御以上列出的某些威胁的屏障。下面我们对它们进行详细的检视。
ViewStateUserKey
从 ASP.NET 1.1 开始引入，ViewStateUserKey 是 Page 类的一个字符串属性，只有很少数开发人员真正熟悉该属性。为什么呢？让我们看看文档中是怎么说的。
在与当前页相关联的视图状态变量中将一个标识符分配给单个用户
除了有些累赘，这个句子的意思相当清楚；但是，您能老老实实地告诉我，它说明了该属性原本的用途吗？要理解 ViewStateUserKey 的角色，您需要继续往下读，直到 Remarks 部分。
该属性有助于防止一次单击攻击，因为它提供了附加的输入以创建防止视图状态被篡改的哈希值。换句话说，ViewStateUserKey 使得黑客使用客户端视图状态的内容来准备针对站点的恶意张贴困难了许多。可以为该属性分配任何非空的字符串，但最好是会话 ID 或用户的 ID。为了更好地理解这个属性的重要性，下面我们简短介绍一下一次单击攻击的基本知识。
一次单击攻击包括将恶意的 HTTP 表单张贴到已知的、易受攻击的 Web 站点。之所以称为“一次单击”，是因为它通常是以受害者不经意的单击通过电子邮件发送的或者在拥挤的论坛中浏览时发现的诱惑性链接而开始的。通过点击该链接，用户无意中触发了一个远程进程，最终导致将恶意的 ＜form> 提交到一个站点。大家都坦白些吧：您真能告诉我，您从未因为好奇而单击过 Click here to win $1,000,000 这样的链接吗？显然，并没有什么糟糕的事情发生在您身上。让我们假定的确是这样的；您能说 Web 社区中的所有其他人都幸免于难了吗？谁知道呢。
要想成功，一次单击攻击需要特定的背景条件：
? 攻击者必须充分了解该有漏洞的站点。这是可能的，因为攻击者可以“勤奋地”研究该文件，或者他/她是一位愤怒的内部人员（例如，被解雇而又不诚实的雇员）。因此，这种攻击的后果可能是极其严重的。
? 站点必须是使用 Cookie（如果是持续性 Cookie，效果更好）来实现单次登录，而攻击者曾经收到过有效的身份验证 cookie。
? 该站点的某些用户进行了敏感的事务。
? 攻击者必须能够访问目标页。

前已提及，攻击包括将恶意的 HTTP 表单提交到等待表单的页。可以推知，该页将使用张贴来的数据执行某些敏感操作。可想而知，攻击者清楚地了解如何使用各个域，并可以想出一些虚假的值来达到他的目的。这通常是目标特定的攻击，而且由于它所建立的三角关系，很难追本溯源 — 即黑客诱使受害者单击该黑客站点上的一个链接，而这又会导致恶意代码被张贴到第三个站点。
为什么是不抱怀疑的受害者？这是因为，这种情况下，服务器日志中所显示的发出恶意请求的 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;
:
}
为了避免重复编写这些代码，您可以将它们固定在从 Page 派生的类的 OnInit 虚拟方法中。（请注意，您必须在 Page.Init 事件中设置此属性。）
protected override OnInit(EventArgs e) {
base.OnInit(e);
ViewStateUserKey = Session.SessionID;
}
总体说来，使用基 page 类始终都不失为一件好事，我在 Build Your ASP.NET Pages on a Richer Bedrock 一文中已经进行了说明。如果您要了解更多有关一次单击攻击者的伎俩的信息，可以在 aspnetpro.com 找到一篇非常好的文章。

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 的过期日期。
＜%@ Page ValidateRequest="false" %>
ValidateRequest不是 万能的药方，无法替代有效的验证层。请阅读此处以获取大量有关该功能的基础原理的宝贵信息。它基本上通过应用一个正则表达式来捕获一些可能有害的序列。
注 ValidateRequest 功能原本是有缺陷的，因此您需要应用一个修补程序它才能按预期工作。这样的重要信息常常不为人们所注意。奇怪的是，我发现我的其中一台计算机仍受该缺陷的影响。试试看！
没有任何关闭 ValidateRequest 的理由。您可以禁用它，但必须有非常好的理由；其中一条这样的理由可能是用户需要能够将某些 HTML 张贴到站点，以便得到更好的格式设置选项。这种情况下，您应当限制所允许的 HTML 标记（＜pre>、＜b>、＜i>、＜p>、＜br>、＜hr>）的数目，并编写一个正则表达式，以确保不会允许或接受任何其他内容。
以下是一些有助于防止 ASP.NET 遭受 XSS 攻击的其他提示：
? 使用 HttpUtility.HtmlEncode 将危险的符号转换为它们的 HTML 表示形式。
? 使用双引号而不是单引号，这是因为 HTML 编码仅转义双引号。
? 强制一个代码页以限制可以使用的字符数。

总之，使用但是不要完全信任 ValidateRequest 属性，不要太过懒惰。花些时间，从根本上理解 XSS 这样的安全威胁，并规划以一个关键点为中心的防御策略：所有的用户输入都是危险的。
数据库角度
SQL 注入是另一种广为人知的攻击类型，它利用的是使用未筛选的用户输入来形成数据库命令的应用程序。如果应用程序兴高采烈地使用用户键入表单域中的内容来创建 SQL 命令字符串，就会将您暴露在这一风险下：恶意用户只需访问该页并输入欺诈参数，就可以修改查询的性质。您可以在此处了解更多有关 SQL 注入的信息。
要阻止 SQL 注入攻击，有许多方法。以下介绍最常见的技巧。
? 确保用户输入属于适当的类型，并遵循预期的模式（邮政编码、身份证号，电子邮件等）。如果预期来自文本框的数字，请在用户输入无法转换为数字的内容时阻止该请求。
? 使用参数化的查询，使用存储过程更好。
? 使用 SQL Server 权限来限制各个用户可以对数据库执行的操作。例如，您可能需要禁用 xp_cmdshell 或者将该操作的权限仅限于管理员。

如果使用存储过程，可以显著降低发生这种攻击的可能性。实际上，有了存储过程，您就无需动态地撰写 SQL 字符串。此外，SQL Server 中将验证所有参数是否具有指定的类型。虽然光是这些并不是百分百安全的技巧，但是加上验证的话，将足以提高安全性。
更为重要的是，应确保只有经过授权的用户才能够执行可能具有严重后果的操作，如删除表。这要求认真仔细地设计应用程序的中间层。好的技巧（不光是为了安全性）应把焦点集中在角色上。应当将用户分组为各种角色，并为各个角色定义一个包含一组最少的权限的帐户。
几周前，Wintellect Web 站点受到一种很复杂的 SQL 注入的攻击。那位黑客试图创建并启动一个 FTP 脚本来下载一个可能是恶意的可执行程序。幸运的是，这次攻击失败了。或者，其实是强用户验证，使用存储过程和使用 SQL Server 权限，导致了攻击未能成功？
总而言之，您应当遵循这些指南，以避免被注入有害的 SQL 代码：
? 使用尽可能少的权限运行，永远不以“sa”身份执行代码。
? 将访问限制给内置的存储过程。
? 首选使用 SQL 参数化查询。
? 不通过字符串串连来生成语句，不回显数据库错误。

 

返回页首
隐藏域
在传统的 ASP 中，隐藏域是唯一一种在请求之间保持数据的方法。您需要在下一个请求中检索的任何数据都被打包到隐藏的 ＜input> 域中，并执行回程。如果有人在客户端上修改了该域中存储的值，会怎样？只要文本是明文的，服务器端环境就无法测知这一情况。ASP.NET 中，页和各个控件的 ViewState 属性有两个用途。一方面，ViewState 是跨请求保持状态的方法；另一方面，ViewState 使您能够在受保护的、不易篡改的隐藏域中存储自定义值。 如图 2 所示，视图状态被附加了一个哈希值，对于每条请求，都会检查该值，以检测是否发生了篡改。除少数几种情况外，没有任何理由要在 ASP.NET 中使用隐藏域。视图状态能够以安全得多的方式实现相同的功能。前面开门见山地讲到过，在明文的隐藏域中存储敏感的值（如价格或信用卡详细信息），相当于对黑客张开大门；视图状态甚至能够使这种不好的做法比以前更为安全，因为视图状态具有数据保护机制。但是，请牢记，视图状态可以防止篡改，但是并不能保证保密性，除非使用加密 — 存储在视图状态中的信用卡详细信息无论如何都有风险。
在 ASP.NET 中，哪些情况下使用隐藏域是可接受的？当您生成需要将数据发送回服务器的自定义控件时。例如，假定您要创建一个支持重派列顺序的新 DataGrid 控件。您需要在回发中将新的顺序发送回服务器。如果不将这些信息存储到隐藏域中，又可以存储到哪里？
如果隐藏域为读/写域，即预期客户端会写入它，没什么办法能够完全制止黑客攻击。您可以尝试哈希或者加密该文本，但这并不能让您合理地确信不会遭受黑客攻击。此时，最好的防御就是让隐藏域包含惰性和无害的信息。
此外，应当注意 ASP.NET 公开了一个鲜为人知的类，可用于编码和哈希任何序列化的对象.该类为 LosFormatter，ViewState 实现用于创建回程到客户端的编码文本正是同一个类。
private string EncodeText(string text) {
StringWriter writer = new StringWriter();
LosFormatter formatter = new LosFormatter();
formatter.Serialize(writer, text);
return writer.ToString();
}
前面的代码片段演示了如何使用 LosFormatter 来创建类似视图状态的内容，对其编码并进行哈希。
电子邮件和垃圾邮件
在本文结尾，请让我指出，最常见的攻击中至少有两种（经典的 XSS 和一次单击）通常是通过诱使不抱怀疑的受害者单击诱惑性和欺骗性的链接来发起的。很多时候我们都可以在自己的收件箱中发现这样的链接，虽然有反垃圾邮件过滤器。几美元就可以买到大量电子邮件地址。用来生成这种列表的其中一种主要的技巧就是扫描 Web 站点上的公共页，查找并获取所有看上去像电子邮件的内容。
如果页上显示了电子邮件地址，很可能或早或晚这个地址都会被自动 Web 程序捕获。真的吗？当然，这要看该电子邮件是如何显示的。如果硬编码它，您输定了。如果采用其他表示形式（如 dino-at-microsoft-dot-com），是否能够骗过自动 Web 程序不太清楚，但能让所有阅读您的页并想建立合法联系的人光火，倒是一定的。
总体说来，您应当确定一种方法，将电子邮件动态地生成为 mailto 链接。Marco Bellinaso 编写的一个免费组件恰好可以完成这项工作。您可以从 DotNet2TheMax Web 站点获得该组件的全部源代码。

小结
有人怀疑 Web 可能是所有运行时环境中敌意最盛的吗？根源在于谁都可以访问 Web 站点，并尝试向它传递好的或坏的数据。但是，创建不接受用户输入的 Web 应用程序，又有什么意义呢？
我们还是直面现实吧：无论您的防火墙如何强大，无论您如何频繁地应用可用的修补程序，只要您运行的 Web 应用程序先天包含缺陷，攻击者迟早都可以通过主通道，也就是端口 80，直接进入您的系统的最核心部分。
ASP.NET 应用程序与其他 Web 应用程序相较，既不更易受攻击，也不更安全。安全性和漏洞同样根植于编码实践、实际经验和团队合作。如果网络不安全，那么任何应用程序都不安全；类似地，无论网络如何安全，管理如何精良，如果应用程序存在缺陷，攻击者总是能够得手。
ASP.NET 的好处是提供了一些好的工具，只需少量工作，就可以将安全标准提升到可以接受的级别。当然，这并不是 足够高的级别。不应纯粹以来 ASP.NET 的内置解决方案，同样也不应忽视它们。尽可能多地了解常见的攻击。