標籤：

IE地址欄的信息是如何泄露的

01-31

IE瀏覽器到底有多不安全

你還在用IE瀏覽器嗎？現如今瀏覽器的種類越來越多，IE瀏覽器幾乎已經快被人們遺忘了。雖然如此對IE瀏覽器的安全研究還是非常有必要的，因為目前還有很多操作是基於它的，另一方面，IE瀏覽器最近幾年也在推陳出新，不斷利用各種方法加強安全性。

但你要知道，Windows目前仍然是被全球黑客攻擊最多的操作系統，所以IE瀏覽器的安全性仍備受質疑。例如，最近肆虐於IE的殭屍腳本漏洞（zombie script bug），雖然該漏洞早在2月份就被披露了，但截至發稿時仍未被修復，你可能會認為這是一個小漏洞影響不大，但我要訴你的是，該漏洞會讓讓所有IE用戶都變為殭屍用戶。這樣，黑客就可以利用該漏洞駐留在受害者的瀏覽器中，當受害者瀏覽不同的網站時，黑客就會有足夠的時間來實施諸如濫用用戶的CPU進行數字貨幣挖掘的惡意行為。此外， IE的阻止彈出窗口功能已經徹底淪為了擺設……雖然IE的問題層出不窮，但我建議大家還是先別著急拋棄它。

在我看來，微軟也正在試圖擺脫IE所帶來的負面效應，讓用戶使用全新的Edge瀏覽器。不過，根據Netmarketshare的統計，目前IE的用戶佔比17％，而Edge的用戶佔比僅為6％，顯而易見，IE仍比Edge受歡迎的多。

雖然我堅信IE應該具備像Edge那樣得到安全技術，但顯然這是妄想。就拿近日發現的一個IE漏洞來說吧，你都想像不到黑客能利用該漏洞來監控用戶IE地址欄的輸入內容。

漏洞介紹

當受害者的IE瀏覽器腳本執行HTML <object>標籤時，黑客利用html標籤就可以獲取位置對象的焦點狀態並讓其返回主位置（main location）而非當前的位置，確切地說，它將返回寫入地址欄文本的位置。有興趣的讀者可以點此觀看視頻，以直觀地了解黑客是如何讀取用戶輸入到IE地址欄里的內容的。

對象和文檔模式

對象標籤的具體運行取決於documentMode的渲染方式，例如，如果用戶在網頁頁面的開頭添加兼容性的HTML <meta>標籤，那它的外觀和運行就像一個HTML <iframe>標籤，也就是說，此時，黑客可以讓受害者的頁面誤認為該標籤是頂層窗口。

<head>n <!-- COMPATIBILITY META TAG -->n <meta http-equiv="X-UA-Compatible" content="IE=8" />n</head>n<object data="obj.html" type="text/html"></object>n

在上面的代碼中，「obj.html」是在對象內部被渲染的，並且被渲染的內容被封裝在與iframe類似的代碼塊中，然而，雖然在窗口對象與頂層對象進行比較時返回值為true，但是它並非頂層窗口。看看在HTML <object>標籤內執行的代碼，可以看出，雖然代碼確定window == top，但顯然這是黑客做得手腳。

你可以點此，詳細查看在IE上進行的測試。

由於受害者的<object>標籤誤認為它是頂層窗口，甚至其他像frameElement這類的對象也總是返回null，目前來看，這種對象行為只發生IE上的頂層窗口。

以上是我在添加了兼容性的HTML <meta>標籤的情況下進行的測試，現在我會嘗試在沒有兼容性標籤的情況下對具有相同的代碼的對象進行測試。從下圖可以看出，該對象已經知道了它所在的位置，並且其行為類似於iframe。

<!-- COMPATIBILITY META TAG REMOVED -->n<object data="obj.html" type="text/html"></object>n

你可以點此，詳細查看在IE上進行的測試。

本質上，該對象在較舊的文檔模式中會被渲染為一個獨立的個體，但如果是在較新的文檔模式中則會被渲染為一個iframe。無論如何，二者的內部都用的是WebBrowser控制項，Trident引擎暴露出的問題也是一樣的。

IE窗口的對象繼承攻擊

再重新說一說documentMode，尋找一種利用這個混淆漏洞的方法，不過該漏洞並非像我想的那麼強大，它還是存在跨域限制的，而且X-Frame-Options響應頭運行的也很好，X-Frame-Options HTTP響應頭是用來確認是否瀏覽器可以在frame或iframe標籤中渲染一個頁面，網站可以用這個頭來保證他們的內容不會被嵌入到其它網站中，以來避免點擊劫持。再比如window.name，它們是通過對象繼承得到的（該對象會繼承其父對象的名稱），攻擊者可以利用window.name+iframe跨域獲取數據，一些廣告技術商會利用該方法實施跨域信息傳遞。

另外一個由對象繼承引起的漏洞，就是位置漏洞。在<object>標籤內，location.href會返回主（頂層）窗口的位置。黑客會利用下面的代碼將其攻擊對象的源代碼指向object_location.html，但是當我檢索它的位置時，它返回的卻是頂層窗口。

你可以點此，詳細查看在IE上進行的測試。

不過要注意的是，只要在同一個域，這個混淆漏洞本身就是沒有用的。即使我可以找到一個頂層的位置來利用該混淆漏洞，但只要在同一個域，還是沒有任何實際效果。如果你想對該話題進行深入研究，我建議你可以嘗試實現UXSS，畢竟，持久性是現實攻擊中一切的關鍵。當對象被注入到onbeforeunload時，我得到的不再是頂級位置，而是瀏覽器的位置到或當前寫入地址欄的內容。

換句話說，如果我在用戶離開主頁面的同時檢索對象的location.href，我將能夠知道他在地址欄中輸入的內容，再或者，如果我點擊鏈接，我將會知道瀏覽器要鏈接的地址。

為了達到我的測試目的，我只會中斷新站點的載入並向用戶顯示URL。當然，在實際的攻擊活動中，攻擊者會直接回填地址並載入站點。實際上，在用戶離開主頁面時，直接執行document.write就行了。

window.onbeforeunload = function()n{n document.write(<object data="loc.html" type="text/html" width_="800" height="300"></object>);n document.close();n}n

並在合適的時機讀取位置（onbeforeunload）。

document.write("Let me read your mind. You wanted to go here: " + location.href +);n

這樣，我就能在用戶離開主頁面時獲取對象位置，進而監控受害者在地址欄中輸入的內容。當然，對象位置不一定是一個完整的URL，例如，用戶在地址欄中輸入的是單詞，那該單詞將自動被轉換為搜索查詢URL（IE默認為Bing），不過，這並不影響對地址欄中輸入內容的完整讀取。

你可以點此，詳細查看在IE上進行的測試。

本文翻譯自：brokenbrowser.com/revea ，如若轉載，請註明原文地址： 4hou.com/web/7827.html 更多內容請關注「嘶吼專業版」——Pro4hou

推薦閱讀：

TAG:信息安全 |