HTTPS頁面中加載HTTP不安全的內容，如何繞過安全警告？
簡介
毫無疑問，如今互聯網正在一步一步向HTTPS安全邁進。大多數大公司都會將證書應用到他們的網站上，以獲得安全保護。這時你可能就有疑問了：這能保證安全到何種程度呢?除了可以抵御中間人攻擊(MITM)，網絡嗅探/篡改等攻擊，HTTPS 協議是否可以避免終端用戶受到來自其他方面的攻擊呢?答案是肯定的。
眾所周知，當前攻擊者使用各種渠道來傳播他們的惡意payload，惡意廣告便是其中之一。他們購買廉價的廣告空間來展示一些廣告內容，但實際上，在這些banner之下，我們總是能夠看到經過混淆的惡意代碼。同時我們還了解到了這些攻擊者是如何判定用戶為潛在受害者或是安全研究人員：即如果鍵盤背后的人是一個毫無經驗的用戶，那么攻擊者會提供完整的惡意payload，否則他們就會偽裝成合法的廣告。
混合內容警告
攻擊者們最近這段事件應該有些頭疼，因為他們的欺騙工作現在只在不安全的頁面才生效了，而瀏覽器默認情況下不會在安全的網站展示不安全的內容。也就是說，如果攻擊者需要被迫通過HTTPS加載代碼，他們的很多欺騙行為(比如檢測文件系統)會失效。設想一下：現下瀏覽器拒絕從安全的域(HTTPS)加載不安全的內容 (HTTP)。這也就是所謂的“混合內容”。
我們打開一個HTTPS網頁的時候，瀏覽器不會加載不安全的內容(例如，一個內含banner的HTTP iframe)。針對這些內容，IE瀏覽器將向用戶發出“顯示所有內容”(重新加載主頁并顯示所有混合內容)的選項。
Edge瀏覽器則會阻止這部分內容，除非用戶使用開發者工具-控制臺窗口查看，否則不會顯示警告。另一方面，如果iframe的來源是不安全的，則會顯示混亂的錯誤信息而不是HTTP內容。
允許加載圖片
但其實也存在例外，即所有瀏覽器都允許無限制加載并渲染不安全的圖片。換句話說，如果攻擊者已經在網絡中進行嗅探，他們可以在遠端查看以及替換圖片。不過實際上，這并不代表著會對用戶構成真正的威脅。早在2011年Eric Lawrence(aka: Internet Hero)就寫了一篇解釋IE團隊允許不提示警告的情況下加載不安全圖像的詳細博文。這很有意義：許多網站使用HTTP協議從外部加載圖片，更糟糕的是，它們在資源中硬編碼了指向本地圖片的HTTP協議，但內容本身(html/scripts)是安全的。所以，它們決定允許image標簽加載沒有警告的渲染器，當加載不安全的內容，地址欄右邊的提示小鎖會消失。
以下為地址欄在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會拒絕解析這些協議，也就避免了運行那些欺騙腳本!也就是說，安全頁面，不僅幫助我們免受中間人攻擊，而且還可以用來阻止執行攻擊者的很多欺騙腳本。
謹記：當攻擊者想要在她的文件系統中檢查用戶是否存在特定文件，他們更傾向于濫用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協議加載的)，然而攻擊者顯然不希望會有這樣的警示信息告知用戶。
不安全的bing.com試圖渲染另一個不安全的內嵌iframe的時候，就會產生這個問題——各位可以體會一下。換言之，即便是在不安全的上級iframe嵌套下，次級嵌套的iframe也需要是安全的。當然我們也可以使用重定向再次加載，但是這并沒什么用，因為攻擊者想要加載IE偽協議(mhtml: res: 和 file:)來實現他們的欺騙行為，而IE拒絕服務器重定向至那些協議。所以我們需要有更好的選擇。
繞過警告信息
我偶然找到了解決方案。我很驚訝，居然是那么基礎的東西：在不安全的 iframe中放一個document.write就夠了。可能這么簡單嗎?
- 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">
我們一旦加載了不安全的內容和document.write，該iframe就可以自由加載不安全的內容而無需重定向。換句話說，這時攻擊者可以加載mhtml/res協議，無限制的施展他們的欺騙手段：IE不知道這些內容正在被渲染，每個嵌入的iframe將完美加載。
最后值得一提的是，Edge瀏覽器雖然受到前面所述重定向欺騙的影響，但document.write這招沒用。或許針對Edge瀏覽器還有其他方法可行，我就不繼續下去了。
得知攻擊者實現他們惡意目的方式如此簡單，我整個人都不好了。
