最近不知道为什么，可能是巧合吧，我接触到了不少关于XSS的东西，这其中也是阅读了一些的关于XSS的文章，由此一来，对XSS也有了一定的认识和思路，当然，这都是以站在巨人的肩膀上为基础的。
在不少人看来，XSS所可能造成的危害程度并不是很大，或者说，一个XSS漏洞的可利用价值并不高，一无非也就是弹框加收集cookie而已。非也！
一个XSS能做的事情其实很多。很多时候看起来一个不起眼的XSS漏洞，在高人的手里，就可能做出一番大动作。
偶然间我在80vul.com看到了一篇名为《WEB2.0下的渗透测试》的文章，其中花了不少的篇幅来阐述XSS漏洞所能够造成的危害及举例。在文章中的实例测试中，成功的利用百度的一个XSS漏洞收集了一些敏感信息，当然，在这个实例当中大可以有更大的动作。
当你把一个XSS拿到手的时候，你会想到它能做些什么？弹个框框？hacked by hacker xxx？收集用户或者管理员的cookie？难道仅此而已？不，我想说你做的这些完全没有发挥出一个XSS的巨大“安全潜能”。借用前辈的一句话：“ xss本质是在于执行脚本[javascript/html等]，而一个javascript就足够让你黑遍这个世界！”。好吧，那下面就让我们来看看XSS的威力到底有多大。
一个javascript就足够让你黑遍这个世界！这句话说的真好。你有没有想过盗取某个站点的用户敏感信息比如账号和密码？或许一个XSS就可以帮你做到这一点！是不是有点难以置信？但事实就摆在你面前。现在在往上流传这样一个js（具体作者不明），实现记录键盘动作，然后每隔固定的时间向客户端发送，当然这并不仅仅局限于用回来盗取用户的账号和密码。我不得不说，把这个js利用在XSS上，的确是一个很BT的想法，不过这也给我们提了个醒：XSS不是没有用，只是看你会不会用，用不用的好。
如果说上面的例子对你没有足够的吸引力的话，那么下面的这个例子应该会让你比较感兴趣了。这个例子让我们更加清晰的理解XSS在不同场景中的不同的应用方式及危害程度以及渗透难度。
最近DEDECMS出了一个变量覆盖漏洞可以说搞的满城风雨，吵得很火。大家都知道，这个变量覆盖漏洞实际上就是因为一个叫做“GPC”的坏蛋引起的。现在的很多PHP WEB程序都喜欢自己模拟register_globals（全局变量注册）的特性，通过GET、POST、cookie等方法注册变量（GPC）。这看起来很美好，可是当我们从安全的角度来看待这个问题的时候，也许就不会那么美妙了。我在80sec中看到了一篇名为《深掘XSS漏洞场景之XSS Rootkit
》的文章，文中正是利用了这一点，模拟了将一个典型的非持久型XSS漏洞变成持久型，其原理就是，由于注册变量的流程是一个foreach循环，所以通过GP注册变量最后能被C覆盖，而cookie是客户端浏览器的持久化数据，通过XSS漏洞来设置cookie，将一个非持久型的XSS变成了一个持久型的XSS。不相信？或者说，想知道文章的作者是怎么做到的？好吧，那我们来一起看一下。
先写出一段设置cookie的javascript代码
Persistence_data=”’>＜script>alert(/xss/)＜/script>’;
var date=new Date();
var expireDays=365; //设置cookie一年后失效
date.setTime(date.getTime()+expireDays*24*3600*1000);
document.cookie=’id=’+Persistence_data+’;expires=’+date.toGMTString(); //设置cookie的id参数值为XSS代码
把设置cookie的javascript代码编码一次，放入XSS URL中，这样防止魔术引号和不同浏览器编码的未知情况影响我们的测试，关闭IE8/9等XSS筛选器后，我们访问下面的URL让XSS生效。
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>
结果令人非常满意，当我们关闭浏览器乃至关闭重启电脑后，再重新访问下面的网页：
无论是访问http://127.0.0.1/demo.php
还是访问http://127.0.0.1/demo.php?id=1
我们的XSS代码都会生效，同时如果客户端未清理cookie，这个XSS漏洞将有效一年的时间，达到了Rootkit隐蔽和能够持久存活的效果。
/* 以上片段摘自《深掘XSS漏洞场景之XSS Rootkit》FROM 80sec */
也许你想要“更加直接的渗透手法”，当然，XSS也一样可以获取到网站的后台管理员，甚至是一个webshell。利用XSS来添加网站后台的管理员账户也许你已经比较熟悉了，是的，经常会有人提到这一点，其实很简单，就是当合法的管理员浏览了一个带有恶意XSS攻击代码页面的时候执行了其中的XSS恶意代码，在无形中执行了添加管理员的操作（一般是通过POST提交数据）。最典型的例子就是在留言本的审核留言当中，我还依稀记得，以前在动易的BBS程序中就出现过这样的XSS漏洞，其原理和上文说的一模一样。那么利用XSS来获得webshell又是怎么一回事呢？可能聪明的你已经想到了，和添加管理员账户的原理是一样的。同样的，这在白盒测试中比较常见。首先找好可以拿webshell的条件和动作，然后利用XSS来提交数据执行这些动作，可以说在原理上是和添加管理员是一模一样的。篇幅限制，本文不再详细解释具体的实施方法和代码，如有需要可参考这方面的文章。
其实一个XSS能做的事情并不止这些，例如我们可以利用一个XSS漏洞来发起一次极为有效的DDOS攻击。曾经在猫扑大杂烩中存在这样一个XSS漏洞，在用户发表回复的时候，程序对用户发表的内容做了严格的过滤，但是我不知道为什么，当用户编辑回复内容再次发表的时候，他却采用了另外一种不同的过滤方式，而这种过滤方式显然是不严密的，因此导致了XSS漏洞的出现。试想一下，像猫扑这样的大型社区，如果在一篇热帖中，利用XSS漏洞来使所有的浏览这篇帖子的用户都在不知不觉之中访问到了另外一个站点，如果这个站点同样是大型站点还好，但如果是中小型站点那就悲剧了，这将会引来多大的流量啊！更可怕的是，这些流量全部都是真实有效的！
本文从安全的角度浅析了XSS漏洞在WEB中所造成的危害。很多程序员对于XSS漏洞并不是很重视，认为XSS漏洞的危害程度不是很高，甚至是无关紧要的，事实上，这就是大错特错了。XSS并不仅仅是弹个框框或者一个死循环的alert那么简单，实际上，利用好XSS完全可以做一些意想不到的事情，而XSS又是普遍存在的，就算是一些大的网站也不能幸免，比如前两天我刚刚发现了优酷某分站和百度团购的XSS，但是由于时间和精力的限制，只是将这些XSS提交上报而没有进行进一步的测试，如果这些XSS漏洞放在一个高人手里，那么所造成的危害就不可估量了。
