閱讀976 返回首頁    go 阿裏雲 go 技術社區[雲棲]

深入分析IE地址欄內容泄露漏洞

前言

在本文中，我們探討的對象是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，但它會認為這是一個頂層窗口。



    

  1. <head> 
    2. 

  2.   <!-- COMPATIBILITY META TAG --> 
    3. 

  3.   <meta http-equiv="X-UA-Compatible" content="IE=8" /> 
    4. 

  4. </head> 
    5. 

  5. <object data="obj.html" type="text/html"></object> 
    6. 

  6.    
    7. 

  7. <head> 
    8. 

  8.   <!-- COMPATIBILITY META TAG --> 
    9. 

  9.   <meta http-equiv="X-UA-Compatible" content="IE=8" /> 
    10. 

  10. </head> 
    11. 

  11. <object data="obj.html" type="text/html"></object> 
    12. 



在上麵的代碼中，“obj.html”在對象內部進行渲染，並且其內容被放入與iframe類似的方框中，然而，雖然在窗口對象與頂層對象進行比較時返回值為true，但是它並非頂層窗口。我們可以看一下在對象標簽內執行的代碼：雖然它認為window
== top，但是事實並非如此。




在IE上進行測試


我們的對象認為它是頂層窗口，甚至其他frameElement之類的成員也總是返回null——這種行為隻出現在(IE的)頂層窗口中。


下麵，讓我們嚐試相同的代碼在沒有兼容性標簽的情況下會怎樣。這時，該對象就能了解它所在的位置了，並且其行為類似於iframe。




在IE上進行測試


本質上，該對象在較舊的文檔模式中被渲染為一個獨立的實體，但在一個較新的文檔模式中將被渲染為一個iframe。無論如何，在內部它們都是WebBrowser控件，所以Trident引擎會暴露相同的成員。


繼承的窗口成員


讓我們重新回到較舊的documentMode，尋找一種利用這個混淆漏洞的方法，不過事情貌似並不那麼糟糕，因為跨域限製仍然存在，而且X-FRAME-OPTIONS頭部的工作效果非常好。
有一些成員，如window.name，它們是通過對象繼承得到的(該對象會繼承其父對象的名稱)，不過這也不是太糟糕——但是某些廣告技術會全地使用window.name來跨iframe傳遞信息，這種做法是很危險的。


話雖如此，至少有一個繼承的對象真的會引起麻煩：位置。在對象標簽內，location.href將返回主(頂層)窗口的位置。下麵的代碼將其對象的源指向object_location.html，但是當我們檢索它的位置時，它返回的是頂層窗口。




在IE上進行測試


再次重申，這個混淆漏洞本身是沒有用的，因為我們仍然在同一個域。即使我們可以找到一個頂層的位置，隻要我們在同一個域，那也沒有多大意思。為此，我嚐試改變對象的位置，但沒有成功。如果你想在這個領域進行研究，我建議可以更深入一些，因為我認為會有更多的可能性。無論如何，在嚐試實現UXSS(持久性是現實攻擊中一切的關鍵)時，我獲得了一個驚喜：當對象被注入到onbeforeunload時，我們得到的不再是頂層窗口的位置，而是瀏覽器的將要到達的位置或當前寫入地址欄的內容。


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


這裏，我們隻是中斷新站點的加載並展示用戶的URL。當然，如果是攻擊者的話，他們會直接回填地址並加載站點，並且這一切對於用戶來說都是透明的。實際上，在用戶離開時，我們直接執行document.write就行了。




    

  1. window.onbeforeunload = function() 
    2. 

  2. { 
    3. 

  3.   document.write('<object data="loc.html" type="text/html" width="800" height="300"></object>'); 
    4. 

  4.   document.close(); 
    5. 

  5. } 
    6. 

  6.    
    7. 

  7. window.onbeforeunload = function() 
    8. 

  8. { 
    9. 

  9.   document.write('<object data="loc.html" type="text/html" width="800" height="300"></object>'); 
    10. 

  10.   document.close(); 
    11. 

  11. } 
    12. 



並在那個恰當的時刻讀取位置(onbeforeunload)。




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


好了，現在我們就能在用戶離開時獲取對象位置，從而確切地知道她在地址欄中輸入的內容。當然，它不一定是一個完整的URL，例如，如果用戶在地址欄中輸入單詞，它將自動被轉換為搜索查詢URL(IE默認為Bing)，這當然可以被完整讀取!




在IE上進行測試











本文作者：佚名


來源：51CTO


最後更新：2017-11-02 16:04:40
  上一篇：go  網絡安全實效性衡量指南：如何作出準確評估 
  下一篇：go  Java反序列化漏洞從理解到實踐