测试Web应用程式是否存在跨站点脚本漏洞
到现在为止，对于跨站点脚本攻击具备很大的威胁这一点大家并无异议。假如您很精通 XSS 并且只想看看有什么好的测试方法可供借鉴，那么请直接跳到本文的测试部分。假如您对此一无所知，请按顺序认真阅读！假如某个怀有恶意的人（攻击者）能够强迫某个不知情的用户（受害者）运行攻击者选择的客户端脚本，那么便会发生跨站点脚本攻击。“跨站点脚本”这个词应该属于用词不当的情况，因为他不但和脚本有关，而且他甚至不一定是跨站点的。所以，他就是个在发现这种攻击时起的一个名字，并且一直沿用至今。从现在开始，我们将使用他常见的缩写名称 “XSS”。
XSS 攻击的过程涉及以下三方：
• 攻击者
• 受害者
• 存在漏洞的网站（攻击者能够使用他对受害者采取行动）
在这三方之中，只有受害者会实际运行攻击者的代码。网站仅仅是发起攻击的一个载体，一般不会受到影响。能够用多种方式发起 XSS 攻击。例如，攻击者可通过电子邮件、IM 或其他途径向受害者发送一个经过经心构造的恶意 URL。当受害者在 Web 浏览器中打开该 URL 的时侯，网站会显示一个页面并在受害者的电脑上执行脚本。
测试 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 来编码您的字符，例如将双引号变为 " 或 "。
6.嗯，并不那么容易，这个站点看来防范比较严密。现在该怎么办呢？
那么，也许您的简单测试用例 <script>alert(‘hi’)</script> 并不能产生期望中的警告对话框。仔细想想这个问题并在可能的情况下和研发人员进行交流。也许他们对输入中的尖括号、单引号或圆括号进行了过滤。也许他们会过滤“script”这个词。重新研究为何输入会产生这样的输出，并理解每个值（查询字符串、cookie、POST 数据）的作用。“pageId=10”这样的查询字符串值可能对输出没有影响，因此不值得花费时间测试他。有时，最好试着注入单个字符（例如尖括号、双引号标记或圆括号），看看应用程式是否过滤这些字符。然后，便能够知道您面对的过滤级别究竟如何。接着，能够调整测试方法，对这些字符进行编码并重试，或寻找其他注入办法。
改变测试用例
我恐怕无法充分对此进行说明：研究输入的值会输出什么样的 HTML 页面很重要。假如他们不能产生输出，那么不要在他们上面浪费时间。假如能够，请进行研究，因为您需要根据输出对测试进行相应的修改。我使用了各种变化形式来找出能接受和显示脚本代码的参数。因为这涉及太多内容，因此在这里无法一一进行讨论，但是请务必注意以下几种情况：
1.>"'><script>alert(‘XSS')</script>
2.>"'><img src="javascript:alert('XSS')">
3.>"'><img src=javascript:alert("XSS")>
4.AK" style="background:url(javascript:alert('XSS'))" OS"
5."+alert('XSS')+"
6.<table background="javascript:alert(([code])"></table>
7.<object type=text/html data="javascript:alert(([code]);"></object>
8.<body></body>
有许多变化形式能够尝试。关键在于了解程式究竟使用何种方式处理输入和显示输出页面。如同这些例子所展示的，常见的变化形式经常是在脚本代码前面加上 “>””，以尝试封闭网站可能在输出中生成的标记。还能够对代码进行 URL 编码，尝试绕过服务器端的输入过滤功能。此外，因为尖括号“<>”通常会在输入时被过滤和从输出中删除，所以还必须尝试无需尖括号的 XSS，例如 ”&{alert('XSS')};”
持久和动态
找出一个成功的 XSS 颇费周折，因为在开始时 XSS 攻击可能并不是那么显而易见的。随便举一个例子，假如向网站添加一条新留言并在“msgTitle”值中注入代码，在提交数据后，您可能不会立即看到脚本代码被执行。但是，当您访问留言板的时侯，将会在 HTML 页面中使用“msgTitle”值并将其作为脚本代码执行。这种情况被称作持久性 XSS 攻击，假如包含脚本代码的值将被保存到客户端或后端系统并在稍候的时间被执行，便会发生此种攻击。
而和此相对的是动态 XSS 攻击，这种攻击会立即执行并只发生一次。比如，假如某个链接或 GET 请求在某个用来控制页面输出的查询字符串中包含了脚本代码，那么在点击链接后会立即显示输出。
总结
XSS 测试通常只是整个 Web 应用程式安全性审查工作的一小部分，但是在执行测试时必须细致和完全。在多年的工作中，我一直强调使用电子表格或其他方式来记录站点的任何页面，连同每个页面接受的输入值（查询字符串、cookie、POST 数据、SOAP），这是在测试前必须进行的一个重要步骤。和此同等重要的是，理解输入连同他在输出的 HTML 页面上的呈现方式。假如您知道了应用程式处理输入的方式，就会很迅速地完成许多工作。不要浪费时间测试那些不会作为输出显示的输入。和研发人员和 PM 进行交流，并在开始测试前建立完善的威胁模型。
XSS 漏洞是什么样的呢？
作为一名 Web 研发人员或测试人员，您肯定知道 Web 应用程式的技术基础是由 HTTP 和 HTML 组成的。HTTP 协议是 HTML 的传输机制，可使用代码设计 Web 页面布局和生成页面。
假如 Web 应用程式接受用户通过 HTTP 请求（如 GET 或 POST）提交的输入信息，然后使用输出 HTML 代码在某些地方显示这些信息，便可能存在 XSS 漏洞。下面是个最简单的例子：
1. Web 请求如下所示：
GET http://www.somesite.com/page.asp?pageid=10&lang=en&title=Section Title
2. 在发出请求后，服务器返回的 HTML 内容包括：
<h1>Section Title</h1>
能够看到，传递给“title”查询字符串参数的用户输入可能被保存在一个字符串变量中并且由 Web 应用程式插入到 <h1> 标记中。通过提供输入内容，攻击者能够控制 HTML。
3. 现在，假如站点没有在服务器端对用户输入加以过滤（因为总是能够绕过客户端控件），那么恶意用户便能够使用许多手段对此漏洞加以滥用：
攻击者能够通过摆脱 <h1> 标记来注入代码：
http://www.somesite.com/page.asp?pageid=10&lang=en&title=Section Title</h1><script>alert(‘XSS attack’)</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 后，便能够执行许多恶意操作，例如窃取他（或她）的凭证。
好了，现在我们已理解了他的危害性 -- 危害用户，危害管理员，给公司带来坏的公共形象。现在，让我们看看本文的重点 -- 测试您的网站是否存在这些问题。
附件列表
文章内容仅供参考，如果您需要解决具体问题建议您提交有问必答。 0
同义词: 暂无同义词
如果您在使用我们的产品中遇到问题，建议您首先在“