前言
在本文中,我們探讨的對象是IE浏覽器,盡管該浏覽器略顯老态,但是其使用者還是很多的,是以不容忽視。我最近對MSRC感到很欣喜,因為他們正在将工作重心移至Edge浏覽器、設計漏洞,甚至提高了漏洞賞金,這看起來确實不錯。
所有這些都是好消息,但我仍然認為現在就急着抛棄IE還為時尚早。例如,現在所有的IE使用者在zombie腳本漏洞(已經公開數月,但是仍然尚未得到修補)面前都可能變成僵屍程式。千萬不要忽視這個問題的嚴重性,請想象一下攻擊者可以做什麼:他們可以一直潛伏在你的浏覽器中,當你浏覽其他網站的時候,他們就有足夠的時間做一些見不得光的事情,比如挖掘數字貨币等。此外,IE的阻止彈出視窗功能已經被完全攻陷了,但是好像并沒有引起人們的注意。總之,我認為這些漏洞應該得到修補,或至少給IE使用者一個醒目的警告,比如“我們不再支援這個浏覽器,請使用Microsoft
Edge”。
在我看來,微軟正在試圖擺脫IE,這個毫無疑問。不過,如果直接告訴使用者他們的舊版浏覽器沒有像Edge那樣得到足夠的維護會顯得更誠實一些。根據Netmarketshare的統計顯示,IE仍比Edge更受歡迎,兩者使用者之比是17% vs 6%。
我堅信在安全方面IE應該像Edge那樣得到同等的對待,否則就應該完全放棄它。但是不管未來怎樣,我們現在先來探讨一下IE上的另一個漏洞:允許攻擊者知道使用者将要浏覽的位址。什麼,這是讀心術嗎?不,當然不是,下面讓我們來看看IE是如何讓攻擊者做出魔幻般的事情的。
摘要
當腳本在object-html标簽内執行時,位置對象将獲得焦點并傳回主位置,而不是它自己的位置。 确切地說,它将傳回寫入位址欄中的文本。如果讀者是急性子的話,可以先觀看視訊,了解一下攻擊者是如何讀取使用者輸入到IE位址欄内的内容的!
對象和文檔模式
對象标簽的行為方式取決于documentMode的渲染方式。 例如,如果我們在頁面的開頭添加相容性元标記的話,它的外觀和行為就像一個iframe,但它會認為這是一個頂層視窗。
<head>
<!-- COMPATIBILITY META TAG -->
<meta http-equiv="X-UA-Compatible" content="IE=8" />
</head>
<object data="obj.html" type="text/html"></object>
在上面的代碼中,“obj.html”在對象内部進行渲染,并且其内容被放入與iframe類似的方框中,然而,雖然在視窗對象與頂層對象進行比較時傳回值為true,但是它并非頂層視窗。我們可以看一下在對象标簽内執行的代碼:雖然它認為window
== top,但是事實并非如此。
<a href="http://s4.51cto.com/wyfs02/M02/A6/4B/wKioL1nMXSSyuRL_AAG5_tz1PSE355.jpg" target="_blank"></a>
在IE上進行測試
我們的對象認為它是頂層視窗,甚至其他frameElement之類的成員也總是傳回null——這種行為隻出現在(IE的)頂層視窗中。
下面,讓我們嘗試相同的代碼在沒有相容性标簽的情況下會怎樣。這時,該對象就能了解它所在的位置了,并且其行為類似于iframe。
<a href="http://s3.51cto.com/wyfs02/M00/07/99/wKiom1nMXazDzERWAAG11cU0RSM469.jpg" target="_blank"></a>
本質上,該對象在較舊的文檔模式中被渲染為一個獨立的實體,但在一個較新的文檔模式中将被渲染為一個iframe。無論如何,在内部它們都是WebBrowser控件,是以Trident引擎會暴露相同的成員。
繼承的視窗成員
讓我們重新回到較舊的documentMode,尋找一種利用這個混淆漏洞的方法,不過事情貌似并不那麼糟糕,因為跨域限制仍然存在,而且X-FRAME-OPTIONS頭部的工作效果非常好。
有一些成員,如window.name,它們是通過對象繼承得到的(該對象會繼承其父對象的名稱),不過這也不是太糟糕——但是某些廣告技術會全地使用window.name來跨iframe傳遞資訊,這種做法是很危險的。
話雖如此,至少有一個繼承的對象真的會引起麻煩:位置。在對象标簽内,location.href将傳回主(頂層)視窗的位置。下面的代碼将其對象的源指向object_location.html,但是當我們檢索它的位置時,它傳回的是頂層視窗。
<a href="http://s3.51cto.com/wyfs02/M01/07/99/wKiom1nMXczTP9lyAAHobEeMqCM636.jpg" target="_blank"></a>
再次重申,這個混淆漏洞本身是沒有用的,因為我們仍然在同一個域。即使我們可以找到一個頂層的位置,隻要我們在同一個域,那也沒有多大意思。為此,我嘗試改變對象的位置,但沒有成功。如果你想在這個領域進行研究,我建議可以更深入一些,因為我認為會有更多的可能性。無論如何,在嘗試實作UXSS(持久性是現實攻擊中一切的關鍵)時,我獲得了一個驚喜:當對象被注入到onbeforeunload時,我們得到的不再是頂層視窗的位置,而是浏覽器的将要到達的位置或目前寫入位址欄的内容。
換句話說,如果我們在使用者離開首頁面的同時檢索對象的location.href,我們将能夠知道她在位址欄中輸入的内容,或者如果點選連結,我們将會獲悉浏覽器要連結的位址。
這裡,我們隻是中斷新站點的加載并展示使用者的URL。當然,如果是攻擊者的話,他們會直接回填位址并加載站點,并且這一切對于使用者來說都是透明的。實際上,在使用者離開時,我們直接執行document.write就行了。
window.onbeforeunload = function()
{
document.write('<object data="loc.html" type="text/html" width="800" height="300"></object>');
document.close();
}
并在那個恰當的時刻讀取位置(onbeforeunload)。
document.write("Let me read your mind. You wanted to go here: " + location.href +);
好了,現在我們就能在使用者離開時擷取對象位置,進而确切地知道她在位址欄中輸入的内容。當然,它不一定是一個完整的URL,例如,如果使用者在位址欄中輸入單詞,它将自動被轉換為搜尋查詢URL(IE預設為Bing),這當然可以被完整讀取!
<a href="http://s2.51cto.com/wyfs02/M01/07/99/wKiom1nMXnDx7MVZAAJX_IwvoRU728.jpg" target="_blank"></a>
本文作者:佚名
來源:51CTO