解析順序問題

    其實哪都一樣，不一定是web世界，前后端解釋型語言，還有HTTP頭部等，

瀏覽器差異帶來的XSS風險1

。都有個解析順序的問題，從上到下，從左到右，從右到左。一旦順序能被干擾，就有可能出現安全問題。比如字符集編碼問題、content-type問題、標簽屬性type問題等等。

    隨便說兩句跑題的，下面才是正文:)

    一些標準實現差異問題

    瀏覽器們都想獨霸世界，有些標準的實現各行其道，導致總是會出現些差異。如果程序員沒意識到這些差異，可能就會引入安全隱患。這部分很多。最近發現瀏覽器們對這個地址的解析差異：

    !@$%">http://www.0×37.com:8989/test.php?c=’”`<>!@$%^*(){}[]:;.,?~

    發送請求時，抓包發現，瀏覽器們的默認行為：

    FireFox

    GET /test.php?c=%27%22%60%3C%3E!@$%^*(){}[]:;.,?~ HTTP/1.1

    Chrome

    GET /test.php?c=’%22`%3C%3E!@$%^*(){}[]:;.,?~ HTTP/1.1

    IE內核

    GET /test.php?c=’”`<>!@$%^*(){}[]:;.,?~ HTTP/1.1

    發現有什么不一樣了？最近我們的掃描器發現了一些主流團購網的XSS，分析時發現了這個，這個差異導致XSS在有的瀏覽器可以成功，有的卻失敗，由于XX原因，案例不能給出，

電腦資料

《瀏覽器差異帶來的XSS風險1》(http://salifelink.com)。不過有經驗的人一看，估計會懷疑，因為%27這些只是urlencode而已，正常輸出的話還是urlencode前的原始字符。所以我懷疑這個差異不應該都怪罪到瀏覽器身上，應該還與這些團購網的具體代碼設計有關系。

    還有一個字符集的差異

    http://www.0×37.com:8989/test.php?c=你好

    頁面默認編碼為utf-8

    發送請求時，抓包發現，瀏覽器們的默認行為：

    FireFox

    GET /test.php?c=%C4%E3%BA%C3 HTTP/1.1

    雙字節編碼，為什么FF會選擇這個？

    Chrome

    GET /test.php?c=%E4%BD%A0%E5%A5%BD HTTP/1.1

    這是utf-8，urlencode的最直接表現。

    IE

    GET /test.php?c=你好 HTTP/1.1

    沒做任何編碼，IE奇怪的很。

    今天pan同學發現某團購網的這個XSS時，也很奇怪為什么XSS只在Chrome上有效，原來Chrome在這個場景中處理中文是走utf-8路線，滿足目標網站。又是團購網。。

    都是比較神奇的XSS。困~還在加班奮戰中，所以寫的有點亂，大家將就看吧。:P