老文章（2009-04-30 19:20），但仍有学习价值，遂转发……
Xss in browser-headers 远程存储
如果把安全的概念推到一个极端，那么一切函数的输出都是有害的。当然，极端的东西不会存在很久，所以我们需要平衡。Xss in browser-headers虽然不是主流的攻击手法，但可能发生的安全问题，我们还是要去关注。如果程序对browser-headers中的数据疏 忽过滤，一旦存到网站后台的数据库中，将会是一个持久型的XSS后门。
构造：
提交后页面：
Xss in browser-headers 本地存储
browser-headers除了会存在到远程数据库中外，其中的某些参数也会存储到本地，比如cookies。前几天我发现http://mail.google.com/support域下存在cookies xss就是一个很好的特例。截图地址：http://hi.baidu.com/xisigr/blog/item/3d875fd1cd95f387a1ec9c24.html
现在我来简单描述一下：
修改cookies 参数，gmail_kimt_exp=')</script><script>alert(document.cookie)</script>。
然后打开http://mail.google.com/support域下任何一个页面，查看HTTP源代码。
HTML文件中将会嵌入如下代码：
<script type="text/javascript">
urchinTracker('/support/?hl=en&experiment=')</script><script>alert(document.cookie)</script>');
</script>
漏洞成因，GOOGLE会把cookies 参数gmail_kimt_exp打印到输出页面中，恰恰gmail_kimt_exp参数输出的时候没有严格过滤。导致XSS漏洞产生。这里要说明的是cookie参数值中不允许有空格存在，所以你在需要用到空格的时候需要编码，比如：
gmail_kimt_exp=')</script><script>
eval(unescape("%64%6F%63%75%6D%65%6E%74%2E%77%72%69%74%65%28%27%3C%69%66%72%61%6D%65%20%73%72%63%3D%68%74%74%70%3A%2F%2F%77%77%77%2E%67%6F%6F%67%6C%65%2E%63%6E%3E%3C%2F%69%66%72%61%6D%65%3E%27%29%3B"))
</script>
这个漏洞GOOGLE已经补上，本质上就是对输出进行了过滤。补丁后的代码如下：
<script type="text/javascript">
urchinTracker('/support/?hl=cn&experiment=\x27)\x3C\x2Fscript\x3E\x3Cscript\x3Ealert(1)\x3C\x2Fscript\x3E');
</script>
那么，有人可能会问，一个存在在本地的XSS又有什么致命的危害呢。
1 留下一个WEB后门，一个super web rookit。
2 大规模 cookies ddos。（前两天好多群里也在讨论这个问题）
现在我们再来回头看Xss in browser-headers这个题目，你是不是已经得到答案。远程数据库持久+本地持久，这就是Xss in browser-headers能做到的。一点也不逊色于其他类型的XSS攻击。