accounts.google.com域下XSS分析

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

原文链接：

http://masatokinugawa.l0.cm/2013/06/accounts.google.com-utf-32-xss.html

具体分析如下：

原本的缺陷地址为：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个“怪怪”的字符来代替双引号和尖括号对的话，会出现什么情况呢？

变为

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

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

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

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

原文作者:gainover

link:http://zone.wooyun.org/content/4448

本文由网络安全攻防研究室（www.91ri.org）信息安全小组收集整理，转载请注明出处。