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.szcgpp.com)信息安全小組收集整理,轉載請注明出處。