测试Web应用程序是否存在跨站点脚本漏洞(XSS)

测试Web应用程序是否存在跨站点脚本漏洞2008年05月26日 星期一 01:37到目前为止,对于跨站点脚本攻击具有很大的威胁这一点大家并无异议。如果您很精通 XSS 并且只想看看有什么好的测试方法可供借鉴,那么请直接跳到本文的测试部分。如果您对此一无所知,请按顺序认真阅读!如果某个怀有恶意的人(攻击者)可以强迫某个不知情的用户(受害者)运行攻击者选择的客户端脚本,那么便会发生跨站点脚本攻击。“跨站点脚本”这个词应该属于用词不当的情况,因为它不仅与脚本有关,而且它甚至不一定是跨站点的。所以,它就是一个在发现这种攻击时起的一个名字,并且一直沿用至今。从现在开始,我们将使用它常见的缩写名称 “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?pageid=10&lang=en&title=Section%20Title

2. 在发出请求后,服务器返回的 HTML 内容包括:
<h1>Section Title</h1>

可以看到,传递给“title”查询字符串参数的用户输入可能被保存在一个字符串变量中并且由 Web 应用程序插入到 <h1> 标记中。通过提供输入内容,攻击者可以控制 HTML。

3. 现在,如果站点没有在服务器端对用户输入加以过滤(因为总是可以绕过客户端控件),那么恶意用户便可以使用许多手段对此漏洞加以滥用:

攻击者可以通过摆脱 <h1> 标记来注入代码:
http://www.somesite.com/page.asp?pageid=10&lang=en&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 后,便可以执行许多恶意操作,例如窃取他(或她)的凭证。

好了,现在我们已经理解了它的危害性 -- 危害用户,危害管理员,给公司带来坏的公共形象。现在,让我们看看本文的重点 -- 测试您的网站是否存在这些问题。

测试 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 或 "。

6.嗯,并不那么容易,这个站点看来防范比较严密。现在该怎么办呢?
那么,也许您的简单测试用例 <script>alert(‘hi’)</script> 并不能产生期望中的警告对话框。仔细想想这个问题并在可能的情况下与开发人员进行交流。也许他们对输入中的尖括号、单引号或圆括号进行了过滤。也许他们会过滤“script”这个词。重新研究为何输入会产生这样的输出,并理解每个值(查询字符串、cookie、POST 数据)的作用。“pageId=10”这样的查询字符串值可能对输出没有影响,因此不值得花费时间。
阅读更多
个人分类: 项目安全性
上一篇常见Web应用安全漏洞初探
下一篇堵住十大安全漏洞 避免Web应用程序的安全风险
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭