Web 应用程序是否存在跨站点脚本漏洞 不得不看~

vegetarian

到目前为止，对于跨站点脚本攻击具有很大的威胁这一点大家并无异议。如果您很精通 XSS 并且只想看

看有什么好的测试方法可供借鉴，那么请直接跳到本文的测试部分。如果您对此一无所知，请按顺序认

真阅读！如果某个怀有恶意的人（攻击者）可以强迫某个不知情的用户（受害者）运行攻击者选择的客

户端脚本，那么便会发生跨站点脚本攻击。室验实TI国中

“跨站点脚本”这个词应该属于用词不当的情况，因为它不仅与脚本有关，而且它甚至不一定是

跨站点的。所以，它就是一个在发现这种攻击时起的一个名字，并且一直沿用至今。从现在开始，我们

将使用它常见的缩写名称“XSS”。
   XSS 攻击的过程涉及以下三方：
   ? 攻击者

   ? 受害者

   ? 存在漏洞的网站（攻击者可以使用它对受害者采取行动）

   在这三方之中，只有受害者会实际运行攻击者的代码。网站仅仅是发起攻击的一个载体，一般不会受

到影响。可以用多种方式发起 XSS 攻击。例如，攻击者可通过电子邮件、IM 或其他途径向受害者发送

一个经过经心构造的恶意 URL。当受害者在 Web 浏览器中打开该 URL 的时侯，网站会显示一个页面并

在受害者的计算机上执行脚本。
   XSS 漏洞是什么样的呢？

   作为一名 Web 开发人员或测试人员，您肯定知道 Web 应用程序的技术基础是由 HTTP 和 HTML 组成

的。HTTP 协议是 HTML 的传输机制，可使用代码设计 Web 页面布局和生成页面。
   如果 Web 应用程序接受用户通过 HTTP 请求（如 GET 或 POST）提交的输入信息，然后使用输出

HTML 代码在某些地方显示这些信息，便可能存在 XSS 漏洞。下面是一个最简单的例子：
   1. Web 请求如下所示：
   GET http://www.somesite.com/page.asp ... tle=Section%20Title
   2. 在发出请求后，服务器返回的 HTML 内容包括：
   <h1>Section Title</h1>
   可以看到，传递给“title”查询字符串参数的用户输入可能被保存在一个字符串变量中并且由 Web

应用程序插入到 <h1> 标记中。通过提供输入内容，攻击者可以控制 HTML。
   3. 现在，如果站点没有在服务器端对用户输入加以过滤（因为总是可以绕过客户端控件），那么恶

意用户便可以使用许多手段对此漏洞加以滥用：
   攻击者可以通过摆脱 <h1> 标记来注入代码：
   http://www.somesite.com/page.asp ... &title=Section%

20Title</h1><script>alert(‘XSS%20attack’)</script>
   这个请求的 HTML 输出将为：
   <h1>Section Title</h1><script>alert(‘XSS attack’)</script>
   即便是这个最简单的例子，攻击者也可以利用此连接完成数不清的事情。让我们看看会有哪些潜在的

威胁，然后讨论一些更高级的测试方法。
   XSS 攻击的威胁有多么严重？
   由于能够在生成的 Web 页面中注入代码，能想到的威胁有多么严重，就可以有多么严重的威胁。攻

击者可以使用 XSS 漏洞窃取 Cookie，劫持帐户，执行 ActiveX，执行 Flash 内容，强迫您下载软件，

或者是对硬盘和数据采取操作。
   只要您点击了某些 URL，这一切便有可能发生。每天之中，在阅读来自留言板或新闻组的受信任的电

子邮件的时侯，您会多少次地单击其中的 URL？
   网络钓鱼攻击通常利用 XSS 漏洞来装扮成合法站点。可以看到很多这样的情况，比如您的银行给你

发来了一封电子邮件，向您告知对您的帐户进行了一些修改并诱使您点击某些超链接。如果仔细观察这

些 URL，它们实际上可能利用了银行网站中存在的漏洞，它们的形式类似于

http://mybank.com/somepage?redirect=<script>alert(‘XSS’)</script>，这里利用了“redirect”

参数来执行攻击。
   如果您足够狡猾的话，可以将管理员定为攻击目标，您可以发送一封具有如下主题的邮件：“求救！

这个网站地址总是出现错误！”在管理员打开该 URL 后，室

验实TI国中便可以执行许多恶意操作，例如窃取他（或她）的凭证。
   好了，现在我们已经理解了它的危害性 -- 危害用户，危害管理员，给公司带来坏的公共形象。现在

，让我们看看本文的重点 -- 测试您的网站是否存在这些问题。
   测试 XSS 漏洞

   多年以来，我一直是一名全职的安全顾问，已经做过无数次的这种测试了。我将好的测试计划归结为

两个字：彻底。对于你我来说，查找这些漏洞与能够有机会在 Bugtraq 或 Vulnwatch 上吹嘘一番没有

任何关系；它只与如何出色完成负责的工作有关。如果这意味着对应用程序中所有的单个查询字符串参

数、cookie 值 以及 POST 数据值进行检查，那么这只能表明我们的工作还不算太艰巨。
   显然，一次完整的安全性检查所涉及的内容通常远远超出寻找 XSS 漏洞那样简单；它需要建立整体

的威胁模型，测试溢出漏洞、信息泄漏、错误处理、SQL 注入、身份验证和授权错误。好在执行这样彻

底的工作时，各个领域之间都存在重叠。比如，在测试 XSS 漏洞时，经常会同时找出错误处理或信息泄

漏问题。
   我假设您属于某个负责对 Web 应用程序进行开发和测试的小组。在这个幸运的位置上，您可以混合

使用黑盒和白盒方法。每种方法都有它自己的优点，结合使用时甚至能相互提供支持。
   1. 按顺序准备您的工具包
   测试工作也可以是自动化的，但是我们在这里只讨论手动操作。手动测试的必备工具包括：
   ? Paros proxy (http://www.parosproxy.org)，用于截获 HTTP 通信数据

   ? Fiddler (http://www.fiddlertool.com/fiddler)，用于截获 HTTP 通信数据

   ? Burp proxy (http://www.portswigger.net/proxy/)

   ? TamperIE (http://www.bayden.com/dl/TamperIESetup.exe)，用于修改 GET 和 POST

   我们以上至少列出了三种 Web 代理软件。也可以寻找其他不同的类似产品，因为每种产品都有它自

己的独到之处。下面，您需要在 Web 浏览器发出 HTTP 请求之前截获这些请求，并修改它们以注入 XSS

测试代码。上面所有这些工具都可以完成这项任务，某些工具还会显示返回的 HTML 源代码（如果您选

择了截获服务器响应）。
   截获客户端发出的 GET 和 POST 请求非常重要。这样可以绕过所有的客户端 javascript 输入验证

代码。我在这里要提醒所有 Web 开发人员 -- 客户端安全控制是靠不住的。应该总是在服务器端执行有

效性验证。

   2. 确定站点及其功能 -- 与开发人员和 PM 交流
   绘制一些简单的数据流图表，对站点上的页面及其功能进行描述。此时，可以安排一些与开发人员和

项目经理的会议来建立威胁模型。在会议上尽可能对应用程序进行深入探讨。站点公开了 Web 服务吗？

是否有身份验证表单？有留言板吗？有用户设置页面吗？确保列出了所有这些页面。

   3. 找出并列出所有由用户提供输入的点
   对站点地图进行进一步细化。我通常会为此创建一个电子表格。对于每个页面，列出所有查询字符串

参数、cookie 值、自定义 HTTP 标头、POST 数据值和以其他形式传递的用户输入。不要忘记搜索 Web

服务和类似的 SOAP 请求，并找出所有允许用户输入的字段。
   分别列出每个输入参数，因为下面需要独立测试每个参数。这可能是最重要的一个步骤！如果阅读下

面的电子表格，您会看到我已经在示例站点中找出了一大堆这样的东西。如 forwardURL 和 lang 这样

的查询字符串。如 name、password、msgBody、msgTitle 和这样的 POST 数据，甚至某些 Cookie 值。

所有这些都是我们感兴趣的重要测试内容。

   4. 认真思考并列出测试用例
   使用已经得到的电子表格并列出各种用来测试 XSS 漏洞的方法。我们稍候将讨论各种方法，但是现

在先让我们看看我的电子表格的屏幕截图，请注意，我列出了页面上允许的每个值以及每个值的所有测

试类型。这种记录测试的方法仅是我自己的习惯，您可以使用自己的方法。我喜欢记录所有东西，以便

我能知道已经做了哪些工作和哪些工作没有做。

   5. 开始测试并注意输出结果
   在查找漏洞的过程中，最重要的部分并不是您是否找到了漏洞。而是您是否真正知道究竟发生了哪些

事情。对于 XSS，只需检查 HTML 输出并看看您输入的内容在什么地方。它在一个 HREF 标记中吗？是

否在 IFRAME 标记中？它在 CLSID 标记中吗？在 IMG SRC 中吗？某些 Flash 内容的 PARAM NAME 是怎

样的？
   我会检查所有这些情况，如果您对所输入内容的目的十分了解，可以调整您的测试来找出问题。这意

味着您可能需要添加一个额外的封闭括号“>”来让某个标记变得完整，或者添加一个双引号来关闭标记

内的一个元素。或者，您可能需要使用 URL 或 HTML 来编码您的字符，例如将双引号变为 %22 或 "。

   嗯，并不那么容易，这个站点看来防范比较严密。现在该怎么办呢？
   那么，也许您的简单测试用例 <script>alert(‘hi’)</script> 并不能产生期望中的警告对话框。

仔细想想这个问题并在可能的情况下与开发人员进行交流。也许他们对输入中的尖括号、单引号或圆括

号进行了过滤。也许他们会过滤“script”这个词。重新研究为何输入会产生这样的输出，并理解每个

值（查询字符串、cookie、POST 数据）的作用。“pageId=10”这样的查询字符串值可能对输出没有影

响，因此不值得花费时间测试它。有时，最好试着注入单个字符（例如尖括号、双引号标记或者圆括号

），看看应用程序是否过滤这些字符。然后，便可以知道您面对的过滤级别究竟如何。接着，可以调整

测试方法，对这些字符进行编码并重试，或者寻找其他注入办法。

vegetarian

改变测试用例
   我恐怕无法充分对此进行说明：研究输入的值会输出什么样的 HTML 页面非常重要。如果它们不能产

生输出，那么不要在它们上面浪费时间。如果可以，请进行研究，因为您需要根据输出对测试进行相应

的修改。我使用了各种变化形式来找出能接受和显示脚本代码的参数。因为这涉及太多内容，因此在这

里无法一一进行讨论，但是请务必注意以下几种情况：
   1. >"'><script>alert(‘XSS')</script>

   2. >%22%27><img%20src%3d%22javascript:alert(%27XSS%27)%22>

   3. >"'><img%20src%3D%26%23x6a;%26%23x61;%26%23x76;%26%23x61;%26%23x73;%26%23x63;%26%

23x72;%26%23x69;%26%23x70;%26%23x74;%26%23x3a;alert(%26quot;XSS%26quot;)>

   4. AK%22%20style%3D%22background:url(javascript:alert(%27XSS%27))%22%20OS%22

   5. %22%2Balert(%27XSS%27)%2B%22

   6. <table background="javascript:alert(([code])"></table>

   7. <object type=text/html data="javascript:alert(([code]);"></object>

   8. <body onload="javascript:alert(([code])"></body>

   有许多变化形式可以尝试。关键在于了解程序究竟使用何种方式处理输入和显示输出页面。如同这些

例子所展示的，常见的变化形式经常是在脚本代码前面加上 “>””，以尝试封闭网站可能在输出中生

成的标记。还可以对代码进行 URL 编码，尝试绕过服务器端的输入过滤功能。此外，因为尖括号“<>”

通常会在输入时被过滤和从输出中删除，所以还必须尝试不需要尖括号的 XSS，例如 ”&{alert

('XSS')};”
   持久和动态
   找出一个成功的 XSS 颇费周折，因为在开始时 XSS 攻击可能并不是那么显而易见的。随便举一个例

子，如果向网站添加一条新留言并在“msgTitle”值中注入代码，在提交数据后，您可能不会立即看到

脚本代码被执行。但是，当您访问留言板的时侯，将会在 HTML 页面中使用“msgTitle”值并将其作为

脚本代码执行。这种情况被称作持久性 XSS 攻击，如果包含脚本代码的值将被保存到客户端或者后端系

统并在稍候的时间被执行，便会发生此种攻击。
   而与此相对的是动态 XSS 攻击，室验实TI国中这种

攻击会立即执行并只发生一次。比如，如果某个链接或 GET 请求在某个用来控制页面输出的查询字符串

中包含了脚本代码，那么在点击链接后会立即显示输出。
   总结
   XSS 测试通常只是整个 Web 应用程序安全性审查工作的一小部分，但是在执行测试时必须细致和彻

底。在多年的工作中，我一直强调使用电子表格或其他方式来记录站点的所有页面，以及每个页面接受

的输入值（查询字符串、cookie、POST 数据、SOAP），这是在测试前必须进行的一个重要步骤。与此同

等重要的是，理解输入以及它在输出的 HTML 页面上的呈现方式。如果您知道了应用程序处理输入的方

式，就会非常迅速地完成许多工作。不要浪费时间测试那些不会作为输出显示的输入。与开发人员和 PM

进行交流，并在开始测试前建立完善的威胁模型。