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

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個“怪怪”的字元來代替雙引号和尖括号對的話，會出現什麼情況呢？

<code>"&lt;script&gt;alert(1)&lt;/script&gt;</code>

變為

<code>∀㸀㰀script㸀alert(1)㰀/script㸀</code>

2. 接着：∀㸀㰀script㸀alert(1)㰀/script㸀 ，在被轉換為UTF-32編碼後，輸出到UTF-8編碼的頁面中，會輸出為以下形式：

<code>[0x00][0x00]"[0x00][0x00][0x00]&lt;[0x00]script[0x00][0x00]&gt;[0x00]alert(1)[0x00][0x00]&lt;[0x00]/script[0x00][0x00]&gt;[0x00]</code>

3. 而在IE10以下的版本(未測試IE9，原文中截圖為IE9，應該可以執行)，HTML中的 [0x00] 會被無視掉，進而導緻上面的代碼被當作普通HTML執行。

空位元組[0x00]不會影響上述代碼的執行，具體見demo: http://xsst.sinaapp.com/nullbyte.htm

4. 為了更直覺的看到這個漏洞，寫了一個PHP頁面，大家自行實驗。

<code>http://xsst.sinaapp.com/utf-32-1.php?charset=utf-32&amp;v=%E2%88%80%E3%B8%80%E3%B0%80script%E3%B8%80alert(1)%E3%B0%80/script%E3%B8%80</code>