FW：推荐使用 Microsoft Anti-Cross Site Scripting Library v3.1

原文一中提到SRE不太适合于ASP.NET MVC架构的Web应用程序，其实是不正确的。

 

原文一在：

推薦使用 Microsoft Anti-Cross Site Scripting Library V3.0

http://blog.miniasp.com/post/2009/07/Recommand-Microsoft-Anti-Cross-Site-Scripting-Library-V30.aspx

原文二在：

推荐使用 Microsoft Anti-Cross Site Scripting Library v3.1

http://blog.miniasp.com/post/2009/09/Recommand-Microsoft-Anti-XSS-Library-V31.aspx

转载开始：

转载一：推荐使用 Microsoft Anti-Cross Site Scripting Library V3.0

微软最近推出了 Microsoft Anti-Cross Site Scripting Library V3.0 正式版(RTM)，但在国内似乎没看到许多人提到这套函示库，就我来观察有几点可能的原因：

从 Wikipedia 上的 Cross-site scripting (XSS) 提到 XSS 有三种类型：

  • 非固定式 XSS 攻击 (Non-persistent)
    1. 这是最常见的攻击类型，日前好几次大规模 XSS 攻击事件都是此类攻击。
    2. 没经验的开发人员最容易遭受此类型的 XSS 攻击。
    3. 像 Request, Request.Form, Request.QueryString, Request.Cookie, Request.Headers 等等都是常见的攻击来源。
  • 固定式 XSS 攻击 (Persistent)
    • 又称 Stored-XSS 攻击。
    • 黑客会试图将「攻击 XSS 字符串」透过各种管道写入到目标网站的数据库中，让浏览网站的用户下载病毒、执行特定脚本、当成 DDoS 的跳板、…等等。
  • 以 DOM 为基础的 XSS 攻击 (DOM-based)
    • 此类型会利用网页透过 JavaScript 动态显示信息到页面中（透过 DOM 修改内容），但内容并未透过 HtmlEncode 过，导致遭黑客传入恶意脚本(JavaScript或VBScript)并让使用者遭殃，或试图修改原有网页中的信息用以欺骗用户执行特定动作或进行信息诈骗。
    • 另一种是透过 Browser 的漏洞将 JavaScript 先写入本机计算机，然后在透过被 XSS 攻击过的网页加载本机 JavaScript 档案进行本机计算机的攻击，例如植入病毒或木马之类的程序。

我们都知道在 ASP.NET 中预设都会阻挡可能会导致 XSS 攻击的字符串，例如 < 或 > 符号。相关信息可参考：How To: Prevent Cross-Site Scripting in ASP.NET 与 Request Validation - Preventing Script Attacks，建议每位开发人员都应该阅读这几篇文章。

不过若因为项目所需，例如「网站后台」为了内容管理的需求可能就会将这项基本防护功能关闭，这时就有可能会让你的数据库被污染，以导致被攻击的 HTML/Scripting 被输出到前台网页上。

有经验的 ASP.NET 开发人员都知道如何撰写阻挡 XSS 的程序代码，一个最简单的也最常见的防护方式就是在页面输出变量时都一律加上 HttpUtility.HtmlEncode 方法，但页面多或开发人员多的时候可就不见得页面每一个地方都能记得加上，除非你有钱购买静态程序代码分析软件定期分析你的 ASP.NET 专案。

从上述得知，你能够在 ASP.NET 专案中做出的努力都称为：「黑名单防护策略」，也就是针对特定网页明确写程序阻挡 XSS 攻击，没写到的地方就破功了。

而采用 Anti-XSS Library 最大的不同就在于它采用「白名单防护策略」，预设将会以最严格的设定预防所有潜在的 XSS 攻击，只有特定编码的字符、允许的特殊符号可以允许通过 HTTP 传输，任何在设定以外的字符或发现潜在的 XSS 攻击行为时就会对相关字符进行编码，例如：HtmlEncode、UrlEncode、LDAP Encode、XPath Encode、… 等。

在安装的时候默认安装路径为：C:\Program Files\Microsoft Information Security\Microsoft Anti-Cross Site Scripting Library v3.0\ ，过程中提供两个选项让你安装：

clip_image003

分别说明如下：

Anti-Cross Site Scripting Library

  • 这个是一个 .NET 组件，提供一个 Microsoft.Security.Application 命名空间，与一个 AntiXSS 类别，类别中有许多静态方法方便开发人员在 ASP.NET 项目中直接套用。
  • 内建的方法包括有HtmlEncode, JavaScriptEncode, UrlEncode, VisualBasicScriptEncode, XmlAttributeEncode, XmlEncode 等，每个方法都有一些特殊方法，值得研究一下。
  • 完整的说明请参见 "C:\Program Files\Microsoft Information Security\Microsoft Anti-Cross Site Scripting Library v3.0\Help\Anti-XSS_Library_Help.chm" 说明文件。
  • 这个 Library 也适用于 ASP.NET MVC 类型的专案。

Security Runtime Engine (SRE)

  • SRE 是一个用 .NET 撰写而成的 HTTP module，可透过 web.config 设定加载 HTTP module 并透过 antixssmodule.config 配置文件的定义（放在应用程序根目录）即可自动保护整个 ASP.NET 网站。（备注：SRE 较不适用于 ASP.NET MVC 专案）
  • 在 C:\Program Files\Microsoft Information Security\Microsoft Anti-Cross Site Scripting Library v3.0\Security Runtime Engine\ConfigGen 目录下有提供一个 ConfigGen.exe 程序可分析 ASP.NET 发布的预先编译网站的 dll 组件，并依据网站内使用的 ASP.NET 控件进行分析，将一些经常遭受 XSS 攻击的控件进行自动防护作业。例如针对 Page.Title 属性、Label 控件的 Text 属性、CheckBox 控件的 Text 属性、…等等。
  • 以下是 antixssmodule.config 的设定范例：

<?xml version="1.0" encoding="utf-8"?>

<Configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<!--This section lists the controls and encoding contexts supported by SRE-->

<ControlEncodingContexts>

<ControlEncodingContext FullClassName="System.Web.UI.WebControls.Label" PropertyName="Text" EncodingContext="Html" />

<ControlEncodingContext FullClassName="System.Web.UI.WebControls.HyperLink" PropertyName="Text" EncodingContext="Html" />

</ControlEncodingContexts>

<!--This section can be used to configure double encoding support-->

<DoubleEncodingFilter Enabled="True" />

<!--This section can be used to configure encoding for derived controls-->

<EncodeDerivedControls Enabled="True" />

<!--This section can be used to configure color coding of the output -->

<MarkAntiXssOutput Enabled="False" Color="Blue"/>

<!--This section includes the configuration for suppressing SRE for the listed files and folders-->

<Suppressions>

<Exclude Path="/Page_1.aspx" />

<Exclude Path="/ExcludedDirectory/Page_2.aspx" />

</Suppressions>

</Configuration>

套用 Security Runtime Engine (SRE) HTTP module 会对网站执行效能带来一些冲击，不过冲击并不大，基于安全考虑应该可以接受。

在 "C:\Program Files\Microsoft Information Security\Microsoft Anti-Cross Site Scripting Library v3.0\Sample Application" 目录下有个简易的范例程序，可以让你彻底感受这套软件的威力，在 web.config 里的 validateRequest 设定为 false 的情况下，也能够让你的网站远离 XSS 攻击的威胁。

ASP.NET MVC 项目建议可以使用 Anti-Cross Site Scripting Library 搭配先前介绍的 CAT.NET 进行网站安全防护与安全检测。

相关连结

 

转载二：推荐使用 Microsoft Anti-Cross Site Scripting Library v3.1

虽然我之前已经写过一篇【 推荐使用 Microsoft Anti-Cross Site Scripting Library V3.0 】文章，而且这次 Anti-XSS Library v3.1 也只有小幅新增功能，但这次新增的两个方法(Methods)却是我盼望许久的功能，终于被我给等到了。我觉得任何开发 ASP.NET Web 应用程序的人都应该注意并使用这一套强大的 Anti-XSS Library，绝对有助于提升你现有 Web 应用程序的安全性。

本次改版新增的 Methods 分别是：

  1. AntiXss.GetSafeHtml 方法：将传入的 HTML 视为一整个页面进行过滤。
  2. AntiXss.GetSafeHtmlFragment 方法：将传入的 HTML 视为一个 HTML 片段进行过滤。

clip_image002

这两个新增的方法 (Methods) 都是用来将传入的字符串/文字转换成「安全的 HTML 语法」，并且支持 串流 (Stream) 处理，所以当要处理大量 HTML 字符串时也非常有效率，且被转换过的 HTML 语法也会被 正规化 (Normalize) 处理，让非标准的 HTML 变成标准的 HTML 语法/格式。

所谓「安全的 HTML 语法」是指当传入的 HTML 包含任何被判定为危险的(malicious)内容就会自动被删除，用以保证最后得到的 HTML 语法是绝对安全的 HTML 版本，让你日后就算程序写在烂也不受 XSS 攻击的威胁，其中包括恶意的 HTML 标签 (例如: script, iframe, link,meta, …)、恶意的 HTML 属性 (例如: onload, onclick, …)、恶意的 CSS 属性 (各位知道在 CSS 中可以插入 JavaScript 执行吗? 如下范例: )

<STYLE type="text/css">BODY{background:url("javascript:alert('XSS')")}</STYLE>

能在CSS 执行 JavaScript 是很多人不知道的开发技巧，但这同时也是黑客最爱玩的 XSS 游戏，不过这语法在新版的浏览器中都被移除了，目前已知支持这语法的浏览器有 万恶的 IE6.0、IE7.0、Firefox 2.0、Opera 9.02 等，有认识朋友还在用 IE6/7 的人赶快请他们升级吧。

我写了一支简单的验证程序，想探探 Anti-XSS Library v3.1 过滤恶意 HTML 的能力，我没写得很复杂，单纯只是想看看转换出来的结果如何。

程序代码如下：

clip_image004

转换出来的结果是：

<div style="color:red; background:#FFF">OK </div>

当我试图将 CSS 的 background 换成 url 的格式

clip_image006

转换出来的结果是：

<div style="color:red">OK </div>

我也更进一步测试了 XSS (Cross Site Scripting) Cheat Sheet 所列的所有 XSS 攻击情境，也确认 Anti-XSS Library 几乎可以防御所有的 XSS 手法 (除了一些非常非常旧的浏览器的XSS弱点之外)，Anti-XSS Library 过滤 HTML 的精准度无庸置疑的好、执行速度也恨快，不管怎样都比你自己过滤 HTML 还来的安全，这毕竟是发展好多年、经过无数次验证过的 Anti-XSS Library 版本，而且这还是完全开放原始码的项目，有兴趣研究、验证 Anti-XSS Library 的人可以到这里下载最新版原始码。

上段提到的一些非常非常旧的浏览器的XSS弱点讲的是在 Netscape 4.0 中的一种非常特殊、诡异的 JavaScript 写法竟然也能运作，如下范例：

<BR SIZE="&{alert('XSS')}">

说实在的，没认真研究过 XSS 的人不会想到 XSS 有多少花招可以玩，你光看 XSS (Cross Site Scripting) Cheat Sheet 所列的所有 XSS 攻击情境就非常有趣了，很多你想都没想到的攻击手法，还有 Ultimate XSS CSS injection 也是很有创意的攻击手法。

一般人在接受网页窗体送出 HTML 时，如果要限制特定卷标才能写入到数据库时，或许会使用类似【清除字符串中的HTML卷标利用RegExp进阶版】的作法，但这样的限制并不完整，还是非常容易被 XSS 攻击，只要透过 HTML Attribute Injection 或 CSS Injection 就能攻击成功，所以建议的作法是：

  1. 先用 Anti-XSS Library v3.1 支援的 AntiXss.GetSafeHtml 或 AntiXss.GetSafeHtmlFragment 方法过滤一遍所有输入的 HTML 字符串。
  2. 然后再过滤不想支持的 HTML 标签，这个时候再使用【清除字符串中的HTML卷标利用RegExp进阶版】作法就非常完美了。

今天一整个下午都在研究 Anti-XSS Library v3.1，我发现里面有个 HtmlToHtml Class 主要负责过滤 HTML 工作，而且写的非常有弹性，当中有个 委派 (delegate) 属性 HtmlTagCallback 可以用来自定义过滤特定标签的程序逻辑，透过这种方式实做过滤卷标的功能也会比用 Regex 实做来的好，只可惜在 Anti-XSS Library v3.1 中将 HtmlToHtml 类标注为 internal 所以没办法直接使用。由于 Anti-XSS Library v3.1 是开放原始码(MS-PL)，如果有需要的人还是可以将这些类移到自己的项目中使用。

相关连结

posted @ 2009-09-27 08:49  Web应用安全观察站  阅读(1253)  评论(0)  编辑  收藏  举报