Xss in browser-headers 远程存储 & 本地存储

    老文章（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=')。

    然后打开http://mail.google.com/support域下任何一个页面，查看HTTP源代码。

    HTML文件中将会嵌入如下代码：

');

    漏洞成因，GOOGLE会把cookies 参数gmail_kimt_exp打印到输出页面中，恰恰gmail_kimt_exp参数输出的时候没有严格过滤。导致XSS漏洞产生。这里要说明的是cookie参数值中不允许有空格存在，所以你在需要用到空格的时候需要编码，比如：

gmail_kimt_exp=')

    这个漏洞GOOGLE已经补上，本质上就是对输出进行了过滤。补丁后的代码如下：

    那么，有人可能会问，一个存在在本地的XSS又有什么致命的危害呢。

1 留下一个WEB后门，一个super web rookit。
2 大规模 cookies ddos。（前两天好多群里也在讨论这个问题）

    现在我们再来回头看Xss in browser-headers这个题目，你是不是已经得到答案。远程数据库持久+本地持久，这就是Xss in browser-headers能做到的。一点也不逊色于其他类型的XSS攻击。

文章来源于lcx.cc:Xss in browser-headers 远程存储 & 本地存储