频道栏目
首页 > 安全 > 网站安全 > 正文

7500刀的accounts.google.com域下XSS分析

2013-06-21 09:42:18      个评论       作者:gainover
收藏   我要投稿

 GOOGLE现在XSS已经涨到3100~7500了,然后某著名日本猥琐流就发了一个accounts.google.com域下的XSS,在微博上看到@xisigr在新浪微博上发了链接,就去看了下,虽然看不懂日文,但还是分析了下。

原文链接:Masato Kinugawa Security Blog: accounts.google.comに存在したXSS

具体分析如下:

原本的缺陷地址为:

https://accounts.google.com/NewAccount?oe=utf-32&Email=%E2%88%80%E3%B8%80%E3%B0%80script%E3%B8%80alert%281%29%E3%B0%80/script%E3%B8%80

根据我自己的理解,其中,oe参数应该是用来指定字段的输出编码(output encoding), email为输入,经过oe所指定的编码进行转换后,输出到页面的 <input type="text" value="[Email]" /> 里。

更简单的说就是, 如果我们Email输入 AAAAAA, oe=gbk 的情况下, AAAAAA --> 转换为 gbk 编码 --> GBK编码下的[AAAAAAA] ,再输出到页面上。

于是,于是,漏洞发现者就猥琐了一把。。。

按照作者的思路,

1.首先, 将输出编码设置为 UTF-32。

UTF-32中,每4个字节表示一个字符,比如

双引号 --> [0x00][0x00][0x00][0x22] <括号 --> [0x00][0x00][0x00][0x3C] >括号 --> [0x00][0x00][0x00][0x3E]

那么更好玩的是,在UTF-32中,这样也是有效字符:

[0x00][0x00][0x22][0x00] --> ∀ [0x00][0x00][0x3C][0x00] --> 㰀 [0x00][0x00][0x3E][0x00] --> 㸀

因而如果我们用上面这3个“怪怪”的字符来代替双引号和尖括号对的话,会出现什么情况呢?

"<script>alert(1)</script>

变为

∀㸀㰀script㸀alert(1)㰀/script㸀

2. 接着:∀㸀㰀script㸀alert(1)㰀/script㸀,在被转换为UTF-32编码后,输出到UTF-8编码的页面中,会输出为以下形式:

[0x00][0x00]"[0x00][0x00][0x00]<[0x00]script[0x00][0x00]>[0x00]alert(1)[0x00][0x00]<[0x00]/script[0x00][0x00]>[0x00]

3. 而在IE10以下的版本(未测试IE9,原文中截图为IE9,应该可以执行),HTML中的 [0x00] 会被无视掉,从而导致上面的代码被当作普通HTML执行。

空字节[0x00]不会影响上述代码的执行,具体见demo: http://xsst.sinaapp.com/nullbyte.htm

4. 为了更直观的看到这个漏洞,写了一个PHP页面,大家自行实验。

http://xsst.sinaapp.com/utf-32-1.php?charset=utf-32&v=%E2%88%80%E3%B8%80%E3%B0%80script%E3%B8%80alert(1)%E3%B0%80/script%E3%B8%80
相关TAG标签
上一篇:高级SQL注入:混淆和绕过
下一篇:XSS+CSRF对ACFUN用户持久劫持与自传播,详细分析与突破手段
相关文章
图文推荐

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训 | 举报中心

版权所有: 红黑联盟--致力于做实用的IT技术学习网站