解析順序問題

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

瀏覽器差異帶來的XSS風(fēng)險1

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

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

    一些標準實現(xiàn)差異問題

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

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

    發(fā)送請求時，抓包發(fā)現(xiàn)，瀏覽器們的默認行為：

    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內(nèi)核

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

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

電腦資料

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

    還有一個字符集的差異

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

    頁面默認編碼為utf-8

    發(fā)送請求時，抓包發(fā)現(xiàn)，瀏覽器們的默認行為：

    FireFox

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

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

    Chrome

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

    這是utf-8，urlencode的最直接表現(xiàn)。

    IE

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

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

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

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