傳統(tǒng)的登錄框

　　在之前的文章流量劫持危害詳細(xì)講解了 HTTP 的高危性，以至于重要的操作都使用 HTTPS 協(xié)議，來保障流量在途中的安全。

　　這是最經(jīng)典的登錄模式。盡管主頁面并沒有開啟 HTTPS，但登錄時(shí)會(huì)跳轉(zhuǎn)到一個(gè)安全頁面來進(jìn)行，所以整個(gè)過程仍是比較安全的 —— 至少在登錄頁面是安全的。

　　對(duì)于這種安全頁面的登錄模式，黑客硬要下手仍是有辦法的。在之前的文章里也列舉了幾種最常用的方法：攔截 HTTPS 向下轉(zhuǎn)型、偽造證書、跳轉(zhuǎn)釣魚網(wǎng)站。

　　其中轉(zhuǎn)型 HTTPS 的手段最為先進(jìn)，甚至一些安全意識(shí)較強(qiáng)的用戶也時(shí)有疏忽。

　　然而，用戶的意識(shí)和知識(shí)總是在不斷提升的。尤其在如今各種網(wǎng)上交易的時(shí)代，安全常識(shí)廣泛普及，用戶在賬號(hào)登錄時(shí)會(huì)格外留心，就像過馬路時(shí)那樣變得小心翼翼。

　　久而久之，用戶的火眼金睛一掃地址欄即可識(shí)別破綻。

　　因此，這種傳統(tǒng)的登錄模式，仍具備一定的安全性，至少能給用戶提供識(shí)別真假的機(jī)會(huì)。

　　華麗的登錄框

　　不知從何時(shí)起，人們開始熱衷在網(wǎng)頁里模仿傳統(tǒng)應(yīng)用程序的界面。無論控件、窗口還是交互體驗(yàn)，紛紛向著本地程序靠攏，效果越做越絢。

　　然而華麗的背后，其本質(zhì)仍是一個(gè)網(wǎng)頁，自然掩蓋不了網(wǎng)頁的安全缺陷。

　　當(dāng)網(wǎng)頁特效蔓延到一些重要數(shù)據(jù)的交互 —— 例如賬號(hào)登錄時(shí)，風(fēng)險(xiǎn)也隨之產(chǎn)生。因?yàn)樗淖兞擞脩舻氖褂昧?xí)慣，同時(shí)也徹底顛覆了傳統(tǒng)的意識(shí)。

　　乍一看，似乎也沒什么問題。雖然未使用登錄頁跳轉(zhuǎn)，但數(shù)據(jù)仍通過 HTTPS 傳輸，途中還是無法被截獲。

　　HTTP 頁面用 HTTPS 有意義嗎？

　　如果認(rèn)為這類登錄框沒什么大問題，顯然還沒領(lǐng)悟到『流量劫持』的精髓 —— 流量不是單向的，而是有進(jìn)也有出。

　　能捕獲你『出流量』的黑客，大多也有辦法控制你的『入流量』。這在流量劫持第一篇里也詳細(xì)列舉了。

　　使用 HTTPS 確實(shí)能保障通信的安全。但在這個(gè)場(chǎng)合里，它只能保障『發(fā)送』的數(shù)據(jù)，對(duì)于『接收』的流量，則完全不在其保護(hù)范圍內(nèi)。

　　因?yàn)檎麄€(gè)登錄框都當(dāng)作『虛擬窗口』嵌套在主頁面里的，因此其中的一切都在同個(gè)頁面環(huán)境里。而主頁面使用的仍是不安全的 HTTP 協(xié)議，所以注入的 XSS 代碼能輕而易舉的控制登錄框。

　　當(dāng)然，或許你會(huì)說這只是設(shè)計(jì)缺陷。若是直接嵌入 HTTPS 登錄頁的 iframe 框架，那就會(huì)因同源策略而無法被 XSS 控制了。

　　這樣的改進(jìn)確實(shí)能提高一些安全性，但也只是略微的。既然我們能控制主頁面，里面顯示什么內(nèi)容完全可以由 XSS 說了算。不論什么登錄框、框架頁，甚至安全插件，我們都可以將其刪除，用看起來完全相同的文本框代替。得到賬號(hào)后，通過后臺(tái)反向代理實(shí)現(xiàn)登錄，然后通知前端腳本偽造一個(gè)登錄成功的界面。

　　所以，HTTPS 被用在 HTTP 頁面里，意義就大幅下降了。

　　和『緩存投毒』配合出擊

　　在流量劫持第二篇里提到『HTTP 緩存投毒』這一概念，只要流量暫時(shí)性的被劫持，都可導(dǎo)致緩存長(zhǎng)期感染。但這種攻擊有個(gè)前提，必須事先找到站點(diǎn)下較穩(wěn)定的腳本資源，做投毒的對(duì)象。

　　傳統(tǒng)登錄

　　在傳統(tǒng)的登錄模式里，緩存投毒非常難以利用：

　　HTTPS 資源顯然無法被感染。

　　而使用 HTTPS 向下轉(zhuǎn)型的方案，也會(huì)因?yàn)殡x開劫持環(huán)境，而無法訪問中間人的 HTTP 版登陸頁面，導(dǎo)致緩存失效；或者這個(gè)真實(shí)的 HTTP 版的登錄頁面根本就不接受你的本地緩存，直接重定向到正常的 HTTPS 頁面。

　　因此只有在主頁面上，修改鏈接地址，讓用戶跳轉(zhuǎn)到釣魚網(wǎng)站去登錄，才能勉強(qiáng)利用。

　　浮層登錄

　　制作一個(gè)精良的浮層登錄框，需要不少的界面代碼，所以經(jīng)常引用 jQuery 這類通用腳本庫(kù)。而這些腳本往往是長(zhǎng)久不會(huì)修改的，因此是緩存投毒的絕好原料。

　　所以，浮層登錄框的存在，讓『緩存投毒』有了絕佳的用武之地。

　　在之前的文章 WiFi流量劫持 —— JS腳本緩存投毒，演示了如何利用 www.163.com 下的某個(gè)長(zhǎng)緩存腳本進(jìn)行投毒，最終利用網(wǎng)易的浮層登錄框獲取賬號(hào)。盡管網(wǎng)易也使用 HTTPS 傳輸賬號(hào)數(shù)據(jù)，但在流量攻擊面前不堪一擊。

　　盡管這種登錄模式風(fēng)險(xiǎn)重重，但最近百度也升級(jí)成浮層登錄框，并且還是所有產(chǎn)品。所以，我們?cè)俅螄L試那套的古老方法，看看在如今是否仍能發(fā)起攻擊。

　　我們選幾個(gè)最常用的產(chǎn)品線，進(jìn)行一次緩存掃描：

　　果然，每個(gè)產(chǎn)品線里都有長(zhǎng)期未修改、并且緩存很久的腳本庫(kù)。

　　接著開啟我們的釣魚熱點(diǎn)，讓前來連接的用戶，訪問任何一個(gè)頁面都能中毒。

　　為了讓釣魚熱點(diǎn)更隱蔽，這次我們不再使用路由器，而是利用報(bào)廢的安卓手機(jī)（下一篇文章詳細(xì)講解如何實(shí)現(xiàn)）。

　　為了不影響附近辦公，本文就不演示同名熱點(diǎn)釣魚了，所以隨便取了個(gè)名字。

　　接著讓『受害者』來連一下我們的熱點(diǎn)：

　　之前正好開著網(wǎng)頁，所以很快收到了 HTTP 請(qǐng)求。我們?cè)谌魏尉W(wǎng)頁里注入 XSS，進(jìn)行緩存投毒。

　　（由于原理和之前講一樣，所以這里就省略步驟了）

　　然后重啟電腦，連上正常的 WiFi（模擬用戶回到安全的場(chǎng)合）。

　　打開 tiebai.baidu.com，一切正常。

　　開始登錄了。。。

　　看看這種浮層登錄框，能否躲避我們的從沉睡中喚起的 XSS 腳本：

　　奇跡依然發(fā)生！

　　由于之前有過詳細(xì)的原理講解，因此這里就不再累述了。不過在實(shí)戰(zhàn)中，緩存投毒+非安全頁面登錄框，是批量獲取明文賬號(hào)的最理想手段。

　　不可逆的記憶

　　如果現(xiàn)在再將登錄模式換回傳統(tǒng)的，還來得及嗎？顯然，為時(shí)已晚。

　　當(dāng)網(wǎng)站第一次從傳統(tǒng)登錄，升級(jí)到浮層登錄時(shí)，用戶大多不會(huì)立即輸入，而是『欣賞』下這個(gè)新版本的創(chuàng)意。確認(rèn)不是病毒廣告彈出的窗口，而是真的官方設(shè)計(jì)的，才開始登錄。

　　當(dāng)用戶多次使用浮層登錄框之后，慢慢也就接受了這種新模式。

　　即使未來，網(wǎng)站取消了浮層登錄，黑客使用 XSS 創(chuàng)建一個(gè)類似的浮層，用戶仍會(huì)毫不猶豫的輸入賬號(hào)。因?yàn)樵谒麄兊挠洃浝铮俜骄驮褂眠^，仍然保留著對(duì)其信任度。

　　安全性升級(jí)

　　既然這個(gè)過程是不可逆的，撤回傳統(tǒng)模式意義也不大。事實(shí)上，使用浮層的用戶體驗(yàn)還是不錯(cuò)的，對(duì)于不了解安全性的用戶來說，還是喜歡華麗的界面。

　　要保留體驗(yàn)，又得考慮安全性，最好的解決方案就是將所有的頁面都使用 HTTPS，將站點(diǎn)武裝到牙齒，不留一絲安全縫隙。這也是未來網(wǎng)站的趨勢(shì)。

it知識(shí)庫(kù)：流量劫持——浮層登錄框的隱患，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。