摘要：簡介毫無疑問，如今互聯(lián)網(wǎng)正在一步一步向HTTPS安全邁進(jìn)。大多數(shù)大公司都會將證書應(yīng)用到他們的網(wǎng)站上，以獲得安全保護(hù)。這時你可能就有疑問了：這能保證安全到何種程度呢?除了可以抵御中間人攻擊(MITM)，網(wǎng)絡(luò)嗅探/篡改等攻擊，HTTPS 協(xié)議是否可以避免終端用戶受到來自其他方面的攻擊呢?答案是肯定的。眾所周知，當(dāng)前攻擊者使用各種渠道來傳播他們的惡意payload，惡意廣告便是其中之一。他們購買廉價的廣
簡介
毫無疑問，如今互聯(lián)網(wǎng)正在一步一步向HTTPS安全邁進(jìn)。大多數(shù)大公司都會將證書應(yīng)用到他們的網(wǎng)站上，以獲得安全保護(hù)。這時你可能就有疑問了：這能保證安全到何種程度呢?除了可以抵御中間人攻擊(MITM)，網(wǎng)絡(luò)嗅探/篡改等攻擊，HTTPS 協(xié)議是否可以避免終端用戶受到來自其他方面的攻擊呢?答案是肯定的。
眾所周知，當(dāng)前攻擊者使用各種渠道來傳播他們的惡意payload，惡意廣告便是其中之一。他們購買廉價的廣告空間來展示一些廣告內(nèi)容，但實際上，在這些banner之下，我們總是能夠看到經(jīng)過混淆的惡意代碼。同時我們還了解到了這些攻擊者是如何判定用戶為潛在受害者或是安全研究人員：即如果鍵盤背后的人是一個毫無經(jīng)驗的用戶，那么攻擊者會提供完整的惡意payload，否則他們就會偽裝成合法的廣告。
混合內(nèi)容警告
攻擊者們最近這段事件應(yīng)該有些頭疼，因為他們的欺騙工作現(xiàn)在只在不安全的頁面才生效了，而瀏覽器默認(rèn)情況下不會在安全的網(wǎng)站展示不安全的內(nèi)容。也就是說，如果攻擊者需要被迫通過HTTPS加載代碼，他們的很多欺騙行為(比如檢測文件系統(tǒng))會失效。設(shè)想一下：現(xiàn)下瀏覽器拒絕從安全的域(HTTPS)加載不安全的內(nèi)容 (HTTP)。這也就是所謂的“混合內(nèi)容”。
我們打開一個HTTPS網(wǎng)頁的時候，瀏覽器不會加載不安全的內(nèi)容(例如，一個內(nèi)含banner的HTTP iframe)。針對這些內(nèi)容，IE瀏覽器將向用戶發(fā)出“顯示所有內(nèi)容”(重新加載主頁并顯示所有混合內(nèi)容)的選項。
Edge瀏覽器則會阻止這部分內(nèi)容，除非用戶使用開發(fā)者工具-控制臺窗口查看，否則不會顯示警告。另一方面，如果iframe的來源是不安全的，則會顯示混亂的錯誤信息而不是HTTP內(nèi)容。
允許加載圖片
但其實也存在例外，即所有瀏覽器都允許無限制加載并渲染不安全的圖片。換句話說，如果攻擊者已經(jīng)在網(wǎng)絡(luò)中進(jìn)行嗅探，他們可以在遠(yuǎn)端查看以及替換圖片。不過實際上，這并不代表著會對用戶構(gòu)成真正的威脅。早在2011年Eric Lawrence(aka: Internet Hero)就寫了一篇解釋IE團(tuán)隊允許不提示警告的情況下加載不安全圖像的詳細(xì)博文。這很有意義：許多網(wǎng)站使用HTTP協(xié)議從外部加載圖片，更糟糕的是，它們在資源中硬編碼了指向本地圖片的HTTP協(xié)議，但內(nèi)容本身(html/scripts)是安全的。所以，它們決定允許image標(biāo)簽加載沒有警告的渲染器，當(dāng)加載不安全的內(nèi)容，地址欄右邊的提示小鎖會消失。
以下為地址欄在IE上加載不安全圖片前后的變化圖。注意主地址欄的安全協(xié)議沒有改變。
同樣的事情我們在Microsoft Edge上進(jìn)行嘗試，但鎖的圖標(biāo)在左邊。如果你想體驗這個過程，可以戳這里。
有趣的是，兩個瀏覽器都認(rèn)為偽協(xié)議(res: mhtml: file:)是不安全的，所以就無法加載這些東西了(就像常規(guī)的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://">
偽協(xié)議行為
你可能會想，HTTPS與這些奇怪的mhtml:和res:協(xié)議有什么聯(lián)系?這些奇怪的協(xié)議被攻擊者用來加載硬盤中的文件，以及用于檢測本地文件的存在。如果主頁是安全的，攻擊者就遇到了一個大問題：IE會拒絕解析這些協(xié)議，也就避免了運(yùn)行那些欺騙腳本!也就是說，安全頁面，不僅幫助我們免受中間人攻擊，而且還可以用來阻止執(zhí)行攻擊者的很多欺騙腳本。
謹(jǐn)記：當(dāng)攻擊者想要在她的文件系統(tǒng)中檢查用戶是否存在特定文件，他們更傾向于濫用mhtml/res/file協(xié)議技術(shù)。 如果你從來沒有見過相關(guān)技巧，建議先看看這篇博文，在這里只需明白一點：當(dāng)下瀏覽器默認(rèn)不允許“混合內(nèi)容”，而且許多欺騙行為在HTTPS下是失效的。
強(qiáng)制加載內(nèi)容
這樣我們就解釋清楚了攻擊者的意圖，所以就需要跟上腳步，嘗試?yán)@過這些警告。
通過上面的內(nèi)容，我們知道了在沒有用戶交互的情況下渲染內(nèi)容的規(guī)則有一個例外情況(image 標(biāo)簽)——于是我嘗試加載以IFRAME(而不是 IMG)作為源的圖片 ，但并沒有成功。之后使用EMBED和OBJECT 元素(兩者都可以渲染html)也沒真正成功。
最后，我試著用常規(guī)IFRAME ，但是使用服務(wù)器重定向來代替直接使用不安全的URL設(shè)置其location屬性。似乎能正常運(yùn)行，內(nèi)容最終成功加載。
Main page should be secure/https The iframe below renders an insecure (http) bing.com <iframe src="http://img.php.cn//upload/image/614/340/635/1480383993705927.jpg">
作為安全研究人員，這個發(fā)現(xiàn)的確非常有趣，但是從攻擊者的角度來看并沒有什么大的卵用。我們已經(jīng)能夠在無用戶交互的情況下加載混合內(nèi)容：由于顯示了不安全的內(nèi)容，瀏覽器會彈出一個警告(bing.com真的是以http協(xié)議加載的)，然而攻擊者顯然不希望會有這樣的警示信息告知用戶。
不安全的bing.com試圖渲染另一個不安全的內(nèi)嵌iframe的時候，就會產(chǎn)生這個問題——各位可以體會一下。換言之，即便是在不安全的上級iframe嵌套下，次級嵌套的iframe也需要是安全的。當(dāng)然我們也可以使用重定向再次加載，但是這并沒什么用，因為攻擊者想要加載IE偽協(xié)議(mhtml: res: 和 file:)來實現(xiàn)他們的欺騙行為，而IE拒絕服務(wù)器重定向至那些協(xié)議。所以我們需要有更好的選擇。
繞過警告信息
我偶然找到了解決方案。我很驚訝，居然是那么基礎(chǔ)的東西：在不安全的 iframe中放一個document.write就夠了。可能這么簡單嗎?
Main page should be secure/https The iframe below renders an insecure (http) bing.com <iframe src="http://img.php.cn//upload/image/659/288/808/1480384146851636.jpg">
我們一旦加載了不安全的內(nèi)容和document.write，該iframe就可以自由加載不安全的內(nèi)容而無需重定向。換句話說，這時攻擊者可以加載mhtml/res協(xié)議，無限制的施展他們的欺騙手段：IE不知道這些內(nèi)容正在被渲染，每個嵌入的iframe將完美加載。
最后值得一提的是，Edge瀏覽器雖然受到前面所述重定向欺騙的影響，但document.write這招沒用?；蛟S針對Edge瀏覽器還有其他方法可行，我就不繼續(xù)下去了。