來源鏈接：https://www.brokenbrowser.com/loading-insecure-content-in-secure-pages/
原作者：MagicMac
譯：Holic (知道創宇404安全實驗室)
毋庸置疑，當今網絡正在向 HTTPS（安全）內容發展。重要的域名現在他們已經將證書準備好了，他們的站點應該是有效且安全的。但是你是不是很好奇：到底能安全到何種程度？顯然，通過 HTTPS 提供的內容是可以抵御中間人攻擊（MITM），網絡嗅探/篡改等方面的攻擊的。但是你有沒有想過， HTTPS 協議是否保護終端用戶免受其他方面的威脅？答案顯然是肯定的。
如我們所知，攻擊者目前使用了廣泛的渠道提供他們的惡意 payload ，惡意廣告便是其中之一。他們購買廉價的廣告空間展示顯眼的廣告，但是在這些 banner 的深處，我們可以發現混淆的惡意代碼。其實，我們已經看到過壞人曾經是如何檢測用戶是否屬于潛在受害者（注：參考 http://www.jmbmsq.com/87/ ），或者檢測出她是個分析人員的。如果鍵盤背后的人是一個不夠精明的用戶，攻擊者會提供完整的惡意 payload ，否則他們只是簡單地偽裝成合法產品的廣告。
混合內容警告
攻擊者現在有個問題，因為他們的技巧只在不安全的頁面有效，而瀏覽器默認情況下不會在安全的網站呈現不安全的內容。具體來說如果攻擊者強行通過 HTTPS 加載他們的代碼，他們的很多技巧（比如檢測文件系統）將無法實施。考慮一點： IE/Edge (和其他瀏覽器) 拒絕從安全的域(HTTPS)加載不安全的內容 (HTTP) .
現代瀏覽器默認情況下不會渲染混合內容（來自安全站點的不安全數據）。如果我們瀏覽 HTTPS 網頁，瀏覽器會拒絕加載不安全的內容（例如，里面有個 banner 的 HTTP iframe）。Internet Explorer 將向用戶發出“顯示所有內容”（重新加載主頁并顯示所有混合內容）的警告。
Edge 還會阻止內容，但除非用戶使用 devtools-console 窗口查看，否則不會顯示警告。此外，如果不安全的內容來自 iframe，則會顯示混亂的錯誤信息。
允許加載圖片
一個有趣的例外是，所有瀏覽器允許無限制加載并渲染不安全的圖像。換句話說，如果攻擊者已經在網絡中進行嗅探，他們將能夠在運行中瀏覽并替換圖片，但這并不代表對最終用戶的真正威脅。一年前 Eric Lawrence (aka: Internet Hero) 寫了一篇博文很清晰地解釋了為什么 IE 的團隊允許不提示警告的情況下加載不安全的圖像。這是很有道理的：許多網站使用 HTTP 協議從外部加載它們的圖像，或更糟的情況，它們在資源中硬編碼了指向本地圖像的 HTTP 協議，但內容本身（html/scripts）是安全的。所以，它們決定允許圖像標簽加載一個沒有警告的渲染器，除了地址欄右邊的小掛鎖會消失。
這是地址欄在 IE 上加載不安全圖片之前和之后的樣子。注意主地址欄的安全協議根本不會改變。我用紅圈標記了鎖，這樣更容易看到。
同樣的事情發生在 Microsoft Edge 上，但鎖的圖標在左邊。如果你想試驗一下，可以在此試一下。
有件有趣的事要記住，兩個瀏覽器都認為偽協議（res: mhtml: file:）是不安全的，所以如果我們嘗試使用這些協議加載內容，都會失敗，就像普通 http 在 https 中那樣。
These iframes won't render anything if the main page is secure/https
<iframe src="http://">
<iframe src="res://">
<iframe src="file://">
<iframe src="mhtml://">
<iframe src="mhtml:res://">使用偽協議的行為
你可能在想，HTTPS 與這些奇怪的 mhtml: 和 res: 協議有什么關系？這些奇怪的協議被使用者用來加載硬盤中的文件，用于檢測本地文件的存在，如果主頁是安全的，他們將有一個大問題：IE 將拒絕解析這些協議。因此不要使用他們的技巧！考慮一下：安全的網頁不僅幫助我們免受 MITM 攻擊，而且作為副作用防止了攻擊者的很多小把戲。
謹記：當攻擊者想要檢查用戶在她的文件系統中是否有特定文件，他們往往使用熟知的技術來利用 mhtml/res/file 協議。 如果你從來沒有見過相關技巧，請看這個技巧相關的博文，但這里需要注意的是：現代瀏覽器默認不允許“混合內容”，而且許多技巧將在 HTTPS 中失效。
強制加載內容
那么現在我們知道了攻擊者的意圖，是時候驗證他們嘗試的技巧了：繞過這些警告。
之前我們知道了在沒有用戶交互的情況下渲染內容的規則（image 標簽）存在著例外情況，我嘗試加載源是圖像的 IFRAME （而不是 IMG），但并沒有成功。然后整了點 EMBED 和 OBJECT 元素（二者皆可渲染 html）也沒真正成功。最后，我決定使用常規 IFRAME ，但是通過使用服務器重定向而不是直接使用不安全的 URL 設置其 location 屬性。這似乎有效，內容終于加載上了。
Main page should be secure/https
The iframe below renders an insecure (http) bing.com
<iframe src="https://www.cracking.com.ar/redir/redir.php?URL=http://www.bing.com">
作為一名研究人員上面這個發現看上去很有趣，但從攻擊者的角度看卻毫無用處。我們已經可以在不經過用戶同意的情況下加載混合內容，但那個警告卻會引起用戶警覺。出現警告是因為加載了不安全的內容（bing.com確實是通過HTTP加載的），所以，攻擊者絕對不會使用這種會引起用戶警覺的手法。 （本段翻譯有疏漏，現已補充，多謝 @psrain 反饋指正）
當不安全的 bing.com 試圖渲染另一個不安全的 iframe 內部內容時，問題便發生了。換句話說，iframe 的子元素也需要是安全的或者是繞過的，相同的技巧也需要進行重定向。但是這并沒什么用，因為攻擊者需要 IE 偽協議（mhtml: res: 和 file:）來實現他們的技巧，而 IE 不接受服務器重定向至那些協議。那么我們需要有更好的選擇。
繞過警告信息
為了找到繞過警告信息的方法，我偶然發現了解決方案。我很驚訝，這個技巧是那么基礎的東西：在不安全的 iframe 中放一個 document.write 就夠了。可能這么簡單嗎？一看便知：
Main page should be secure/https
The iframe below renders an insecure (http) page which does a document.write
<iframe src="https://www.cracking.com.ar/redir/redir.php?URL=http://unsafe.cracking.com.ar">
The HTML code in the iframe is quite simple:
<script>document.write()</script>一旦加載了不安全的內容和 document.write ，iframe 就可以自由加載不安全的內容了，而且無需重定向。換句話說，這時攻擊者可以加載 mhtml/res 協議，無限制施展他們的技巧：IE 不知道這些內容是正在被渲染的，每個嵌入的 iframe 將加載無誤。
Edge 瀏覽器受該重定向技巧的漏洞影響，但 document.write 的方法并不奏效。也許另有途徑，但我在此停頓下來，我知道攻擊者仍然有簡單的方法來達到他們的惡意目的。
本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.jmbmsq.com/112/
暫無評論