1 前言
近年来，随着Web2.0的大潮，越来越多的人开始关注Web安全，新的Web攻击手法层出不穷，Web应用程序面临的安全形势日益严峻。
跨站脚本攻击（XSS）就是常见的Web攻击技术之一，由于跨站脚本漏洞易于出现且利用成本低，所以被OWASP列为当前的头号Web安全威胁。
本文将从跨站脚本漏洞的产生原理、攻击手法、检测方法和防御手段四个方面出发，全面的介绍跨站脚本漏洞的方方面面，为开发人员、安全测试人员以及对Web安全感兴趣的同学提供一份跨站脚本漏洞的技术参考手册。
2 跨站脚本漏洞介绍
2.1 什么是跨站脚本漏洞
跨站脚本漏洞（Cross Site Scripting，常简写作XSS）是Web应用程序在将数据输出到网页的时候存在问题，导致攻击者可以将构造的恶意数据显示在页面的漏洞。因为跨站脚本攻击都是向网页内容中写入一段恶意的脚本或者HTML代码，故跨站脚本漏洞也被叫做HTML注入漏洞（HTML Injection）。
与SQL注入攻击数据库服务器的方式不同，跨站脚本漏洞是在客户端发动造成攻击，也就是说，利用跨站脚本漏洞注入的恶意代码是在用户电脑上的浏览器中运行的。
2.2 跨站脚本漏洞的危害
跨站脚本攻击注入的恶意代码运行在浏览器中，所以对用户的危害是巨大的——也需要看特定的场景：跨站脚本漏洞存在于一个无人访问的小站几乎毫无价值，但对于拥有大量用户的站点来说却是致命的。
最典型的场景是，黑客可以利用跨站脚本漏洞盗取用户Cookie而得到用户在该站点的身份权限。据笔者所知，网上就有地下黑客通过出售未公开的GMail、雅虎邮箱及hotmail的跨站脚本漏洞牟利。
由于恶意代码会注入到浏览器中执行，所以跨站脚本漏洞还有一个较为严重的安全威胁是被黑客用来制造欺诈页面实现钓鱼攻击。这种攻击方式直接利用目标网站的漏洞，比直接做一个假冒网站更具欺骗性。
另外，控制了用户的浏览器，黑客还可以获取用户计算机信息、截获用户键盘输入、刺探用户所处局域网信息甚至对其他网站进行GET Flood攻击。目前互联网已经有此类利用跨站脚本漏洞控制用户浏览器的黑客工具出现。
当然，虽然跨站脚本攻击是在客户端浏览器进行，但是最终也是可以攻击服务器的。笔者就曾在安全测试过程中就利用某Blog程序的跨站脚本漏洞得到网站管理员身份并最终控制Web服务器。
2.3 跨站脚本漏洞的产生
跨站脚本漏洞是如何产生的呢？
大部分Web漏洞都源于没有处理好用户的输入，跨站脚本也不例外。
请看以下一段PHP代码：
<?PHP
echo "欢迎您，".$_GET['name'];
?>
稍微解释一下
，这段PHP代码的意思是在页面输出字符串“欢迎您，”和URL中name参数的值，比如用浏览器访问这个文件：localhost/test23.php?name=lakehu，页面上就会出现“欢迎您，lakehu”字样。其中lake
hu是我们通过URL中的参数name传入的，name的值就是用户的输入。
我们知道，浏览器对网页的展现是通过解析HTML代码实现的，如果我们传入的参数含有HTML代码呢？对，浏览器会解析它而不是原封不动的展示——这个就与Web应用程序的设计初衷相反吧。
这样通过参数访问刚才的PHP页面：localhost/test23.php?name=lake<s>hu</s>，你将看到HTML标记被浏览器解释了：
变本加厉的，如果传入一段脚本<script>[code]</script>，那么脚本也会执行。用这样的URL将会执行JavaScript的alert函数弹出一个对话框：localhost/test.php?name=lake<script>alert(123456)</script>
通过上面简单的示例我们已经知道，Web应用程序在处理用户输入的时候没有处理好传入的数据格式就会导致脚本在浏览器中执行，这就是跨站脚本漏洞的根源。
2.4 跨站脚本漏洞的分类
2.4.1 非持久型XSS
非持久型XSS（Non-persistent）又叫做反射XSS（Reflect XSS），它是指那些浏览器每次都要在参数中提交恶意数据才能触发的跨站脚本漏洞。
前一节演示的XSS漏洞属于这种类型，因为每次我们都是需要向参数name中提交恶意数据来实现跨站脚本攻击。
一般来说，凡是通过URL传入恶意数据的都是非持久型XSS。当然，也有通过表单POST的XSS例子：
<?PHP
echo "欢迎您，".$_POST['name'];
?>
Web应用程序获取的参数name已经由GET变为POST了，要触发这个XSS漏洞就要稍微复杂一点，我们需要写一个网页：
<form action="localhost/test.php" method="post">
<input name="name" value="<script>alert(123456)</script>" type="hidden" />
<input name="ss" type="submit" value="XSS提交测试" />
</form>
点击“XSS提交测试”按钮，你就又会看到浏览器弹出了可爱的对话框?
2.4.2 持久型XSS
持久型XSS（Persistent）又叫做存储XSS（Stored XSS），与非持久型XSS相反，它是指通过提交恶意数据到存储器（比如数据库、文本文件等），Web应用程序输出的时候是从存储器中读出恶意数据输出到页面的一类跨站脚本漏洞。
看个例子。
下图是某BBS程序没有处理发帖正文中的恶意代码就直接存储到数据库中：
然后读帖子的时候程序从数据库中读出数据，结果数据中含有的恶意代码在浏览器执行了（此处仅演示弹出对话框）：
这个漏洞是由于程序会把UBB代码[IMG]javascript:alert('XSS')[/IMG]转换成HTML代码：
<img src="javascript:alert('XSS')" />    IE6会
解析上面的HTML代码并执行img标签src属性中的JavaScript代码，导致XSS的发生。
持久型XSS多出现在Web邮箱、BBS、社区等从数据库读出数据的正常页面（比如BBS的某篇帖子中可能就含有恶意代码），由于不需要浏览器提交攻击参数，所以其危害往往大于非持久型XSS。
2.5 跨站脚本漏洞的出现场景
根据数据输出的不同，跨站脚本漏洞一般会出现在以下4个地方，了解了漏洞出现的场景，对我们认识和修复漏洞是有积极意义的。
2.5.1 输出在HTML页面
前面2.3节的PHP代码就是把数据输出到HTML页面的例子。这种情况比较简单，就是把传入的参数值直接显示在页面，主要就是传入的参数中带有“<”和“>”符号会被浏览器解析。
2.5.2 输出在HTML属性中
看这样一段代码：
<?PHP
echo "<a href=\"".$_GET['name']."\">Enter</a>";
如何查看html代码
?>
这段PHP代码的意思就是把得到的name参数输出到一段HTML标记的A标签中，假设name的值是test，那么你将得到这样的页面：
<a href="test">Enter</a>
这时我们再武断地给name附上“test<script>alert(123456)</script>”是不会造成XSS攻击的，因为脚本会被浏览器认为是href的值，这时候需要稍微动点脑子才行：localhost/test2521.php?name=test">Hi</a><script>alert(123456)</script><!--
得到这样的页面：
<a href="test">Hi</a><script>alert(123456)</script><!—">Enter</a>
请注意，蓝字体为PHP程序输出，而红字体是我们提交的参数。哈哈，我们提交的“">”和“</a>”闭合了原来的A标签，然后跟上JavaScript代码，之后的A标签的后部分被<--注释掉了。
以上就是传入数据输出到属性中的情况，关键点是我们提交的数据能够闭合属性标签。这个例子是双引号，其实属性也是可以用单引号甚至不用引号的（如果属性的值中没有空格的话就可以不需要引号），道理都是一样的，只要闭合它们就可以了。
2.5.3 输出在JavaScript代码中
JavaScript和HTML结合紧密，所以有时候程序员们就会把参数输出到JavaScript代码中：
<?PHP
echo "<script>";
echo "var yourname = '".$_GET['name']."';";
echo "</script>";
?>
分析PHP代码输出的页面，我们很容易构造出XSS攻击测试URL：localhost/test2531.php?name=a';alert(123456);//
实际上是我们利用单引号闭合了JavaScript代码的变量赋值，然后再执行我们的alert函数（因为PHP5在默认情况下是会自动对传入的单引号转义的，这里只是为了演示，所以我们认为此处单引号不被转义。即假设PHP的magic_quote_gpc为Off）。
得到的返回页面是这样的：
<script>
var yourname = 'a';alert(123456);//';
</script>    然后你又看到那个显示123456表示脚本被执行的
演示对话框了。
同样的道理，如果是用的双引号做变量赋值就需要传双引号进去破坏掉原来的JavaScript代码。
2.5.4 基于DOM
DOM是Document Object Model（文档对象模型）的缩写。据W3C DOM规范（/DOM/），DOM是一种与浏览器，平台，语言无关的接口，使得你可以访问页面其他的标准组件。
简单理解，我们把DOM认为是JavaScript输出的页面，基于DOM的跨站脚本漏洞就是出现在JavaScript代码中的漏洞。请注意，之前的3种输出是属于Web应用程序（CGI程序）代码中的漏洞。
是的，你没有看错，含有JavaScript静态HTML页面也可能会存在XSS漏洞。
以下是一段存在DOM类型跨站脚本漏洞的代码：
<script>
document.write(window.location.search);
</script>
在JS中window.location.search是指URL中?之后的内容，document.write是将内容输出到页面。于是乎，又是一个直接输出到页面的跨站脚本漏洞。好，来构造攻击URL：localhost/test2541.php?<script>alert(123456)</script>
但是查看网页源代码，源代码却没变：
这就是DOM，在浏览器的解析中改变页面结构。这种特性检测DOM的跨站脚本漏洞带来了一点麻烦，因为它不能通过页面源代码来判断漏洞，给自动化漏洞检测带来了挑战。
3 跨站脚本漏洞检测技术
3.1 黑盒测试
黑盒测试是指在不知道源代码的情况下通过各种技术手段对Web应用程序进行的探测，这个就是从黑客的视角去发现问题。
3.1.1 测试原理
测试跨站脚本漏洞的原理很简单，就是我们尝试提交可能有问题的数据，然后分析返回页面。
一般是修改参数值为一个标志字符串，然后搜索页面是否含有该字符串。如果有，说明页面会把参数输出。接着就是分析返回页面构造攻击参数，前面2.5提到了4种场景，根据不同的场景有不同的攻击参数。
以2.3节中的代码为例，要测试这个URL，我们就先提交localhost/test23.php?name=XSSTest，然后在返回的页面中搜索到字符“XSSTest”，说明name参数的值是直接输出到页面的。接着我们分析页面，发现name参数的值是直接输出到页面的，所以跟着提交一个含有HTML标记的字符串：localhost/test23.php?name=<b>XSS< /b>，返回页面中仍然发现有“<b>XSS</b>”，而且页面中的“<b>XSS</b>” 已经被浏览器解析，至此，可以判断该URL存在跨站脚本漏洞。
对于DOM跨站脚本漏洞的测试，就不能搜索页面源代码是否含有传入的标志字符串了，稍微复杂一点，可能需要阅读JavaScript代码、观察页面内容并查看页面是否出现JavaScript代码异常等行为。常见的出问题的代码是eval、 document.write、document.writeln、Script、标签
的innerHTML属性、标签的src属性。
3.1.2 常用测试用例
因为跨站脚本漏洞是在浏览器中执行的，而各个浏览器对HTML标签及JavaScript解释有所不同，所以攻击代码其实就根据浏览器的不同而不同。
比如下面的HTML在IE6下会执行JavaScript弹出对话框，但是在IE7及Firefox下就不会执行：
<img src="javascript:alert(123456)" />
而且就上面一段测试用例就还有很多种变形，以下是一小部分：
<img src="javasc
ript:alert(123456)" />
回车分割
<img src="jav ascript:alert(123456)" />
Tab分割
<IMG 
SRC=javascript
:alert('123456')>
面对XSS漏洞的那么多用例和变形，是不是有些头晕了？呵呵，好在有个叫Rsnake的老外按照浏览器分类及变形归纳了一份XSS测试手册（XSS Cheat Sheet），你可以去他的网站到它：/xss.html
如图所示，XSS Cheat Sheet几乎归纳了所有的XSS利用形式及支持的浏览器，实在是XSS研究的最佳资料。
3.1.3 测试自动化——使用Web漏洞扫描器
当我们熟练了之后，测试就是体力活了，而且URL数量很多的话人工也忙不过来，所以我们要把测试工作自动化。
这个时候可以使用Web漏洞扫描器来实现对跨站脚本漏洞的检测，免费的软件有ProxyStrike、Paros、WebScarab等，商业的扫描器有 AppScan、WebInspect等，这些都是比较自动化进行Web漏洞测试的工具，有兴趣的同学可以google一把下载来试用。
当然，扫描器只是提高效率的工具，并不能完全代替手动测试，因为扫描器受到规则和技术的限制，可能会有误报甚至漏报。比如BBS发帖这种交互性很强的地方扫描器很难对其进行测试——人工测试还是必不可少的。
3.2 白盒测试
白盒测试就是阅读代码漏洞了，这种测试方案适合公司内部以及开源项目。这种基于代码检测的方案也叫做代码审计（Code Audit）。
3.2.1 测试原理
简单的说，就是根据相关语言定义一些可能导致跨站脚本漏洞的函数（一般为输出函数），然后去检查这些函数的参数是否由外部传入且未经过安全处理。
比如PHP，就是检查echo、print函数的参数是否来自外部并且没有经过防跨站处理就直接显示到页面；对ASP来说，就是response.write之类的输出函数。
比如这样的PHP代码就有问题：
<?PHP
echo “欢迎您，”.$_GET[‘name’];
?>
这个时候就先定位echo函数，然后发现其输出的值来自外部（$_GET[‘name’]）而且未作安全处理。
其他的语言也是一样的道理。
3.2.2 测试自动化——使用代码审计工具
还是使用工具来提高效率

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。