测试XSS 漏洞

ruanyongjie · 发表于 2008-9-2 23:55:33

对于查找这些漏洞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”这样的查询字符串值可能对输出没有影响，因此不值得花费时间测试它。有时，最好试着注入单个字符（例如尖括号、双引号标记或者圆括号），看看应用程序是否过滤这些字符。然后，便可以知道您面对的过滤级别究竟如何。接着，可以调整测试方法，对这些字符进行编码并重试，或者寻找其他注入办法。

改变测试用例

我恐怕无法充分对此进行说明：研究输入的值会输出什么样的 HTML 页面非常重要。如果它们不能产生输出，那么不要在它们上面浪费时间。如果可以，请进行研究，因为您需要根据输出对测试进行相应的修改。我使用了各种变化形式来找出能接受和显示脚本代码的参数。因为这涉及太多内容，因此在这里无法一一进行讨论，但是请务必注意以下几种情况：

有许多变化形式可以尝试。关键在于了解程序究竟使用何种方式处理输入和显示输出页面。如同这些例子所展示的，常见的变化形式经常是在脚本代码前面加上 “>””，以尝试封闭网站可能在输出中生成的标记。还可以对代码进行 URL 编码，尝试绕过服务器端的输入过滤功能。此外，因为尖括号“<>”通常会在输入时被过滤和从输出中删除，所以还必须尝试不需要尖括号的 XSS，例如 ”&{alert(XSS)};”

持久和动态
   找出一个成功的 XSS 颇费周折，因为在开始时 XSS 攻击可能并不是那么显而易见的。随便举一个例子，如果向网站添加一条新留言并在“msgTitle”值中注入代码，在提交数据后，您可能不会立即看到脚本代码被执行。但是，当您访问留言板的时侯，将会在 HTML 页面中使用“msgTitle”值并将其作为脚本代码执行。这种情况被称作持久性 XSS 攻击，如果包含脚本代码的值将被保存到客户端或者后端系统并在稍候的时间被执行，便会发生此种攻击。
      而与此相对的是动态 XSS 攻击，这种攻击会立即执行并只发生一次。比如，如果某个链接或 GET 请求在某个用来控制页面输出的查询字符串中包含了脚本代码，那么在点击链接后会立即显示输出。