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