|
|
傳統(tǒng)的登錄框
在之前的文章流量劫持危害詳細(xì)講解了 HTTP 的高危性，以至于重要的操作都使用 HTTPS 協(xié)議，來(lái)保障流量在途中的安全。
這是最經(jīng)典的登錄模式。盡管主頁(yè)面并沒(méi)有開(kāi)啟 HTTPS，但登錄時(shí)會(huì)跳轉(zhuǎn)到一個(gè)安全頁(yè)面來(lái)進(jìn)行，所以整個(gè)過(guò)程仍是比較安全的 —— 至少在登錄頁(yè)面是安全的。
對(duì)于這種安全頁(yè)面的登錄模式，黑客硬要下手仍是有辦法的。在之前的文章里也列舉了幾種最常用的方法：攔截 HTTPS 向下轉(zhuǎn)型、偽造證書(shū)、跳轉(zhuǎn)釣魚(yú)網(wǎng)站。
其中轉(zhuǎn)型 HTTPS 的手段最為先進(jìn)，甚至一些安全意識(shí)較強(qiáng)的用戶也時(shí)有疏忽。
然而，用戶的意識(shí)和知識(shí)總是在不斷提升的。尤其在如今各種網(wǎng)上交易的時(shí)代，安全常識(shí)廣泛普及，用戶在賬號(hào)登錄時(shí)會(huì)格外留心，就像過(guò)馬路時(shí)那樣變得小心翼翼。
久而久之，用戶的火眼金睛一掃地址欄即可識(shí)別破綻。
因此，這種傳統(tǒng)的登錄模式，仍具備一定的安全性，至少能給用戶提供識(shí)別真假的機(jī)會(huì)。
華麗的登錄框
不知從何時(shí)起，人們開(kāi)始熱衷在網(wǎng)頁(yè)里模仿傳統(tǒng)應(yīng)用程序的界面。無(wú)論控件、窗口還是交互體驗(yàn)，紛紛向著本地程序靠攏，效果越做越絢。
然而華麗的背后，其本質(zhì)仍是一個(gè)網(wǎng)頁(yè)，自然掩蓋不了網(wǎng)頁(yè)的安全缺陷。
當(dāng)網(wǎng)頁(yè)特效蔓延到一些重要數(shù)據(jù)的交互 —— 例如賬號(hào)登錄時(shí)，風(fēng)險(xiǎn)也隨之產(chǎn)生。因?yàn)樗淖兞擞脩舻氖褂昧?xí)慣，同時(shí)也徹底顛覆了傳統(tǒng)的意識(shí)。
乍一看，似乎也沒(méi)什么問(wèn)題。雖然未使用登錄頁(yè)跳轉(zhuǎn)，但數(shù)據(jù)仍通過(guò) HTTPS 傳輸，途中還是無(wú)法被截獲。
HTTP 頁(yè)面用 HTTPS 有意義嗎？
如果認(rèn)為這類登錄框沒(méi)什么大問(wèn)題，顯然還沒(méi)領(lǐng)悟到『流量劫持』的精髓 —— 流量不是單向的，而是有進(jìn)也有出。
能捕獲你『出流量』的黑客，大多也有辦法控制你的『入流量』。這在流量劫持第一篇里也詳細(xì)列舉了。
使用 HTTPS 確實(shí)能保障通信的安全。但在這個(gè)場(chǎng)合里，它只能保障『發(fā)送』的數(shù)據(jù)，對(duì)于『接收』的流量，則完全不在其保護(hù)范圍內(nèi)。
因?yàn)檎麄€(gè)登錄框都當(dāng)作『虛擬窗口』嵌套在主頁(yè)面里的，因此其中的一切都在同個(gè)頁(yè)面環(huán)境里。而主頁(yè)面使用的仍是不安全的 HTTP 協(xié)議，所以注入的 XSS 代碼能輕而易舉的控制登錄框。
當(dāng)然，或許你會(huì)說(shuō)這只是設(shè)計(jì)缺陷。若是直接嵌入 HTTPS 登錄頁(yè)的 iframe 框架，那就會(huì)因同源策略而無(wú)法被 XSS 控制了。
這樣的改進(jìn)確實(shí)能提高一些安全性，但也只是略微的。既然我們能控制主頁(yè)面，里面顯示什么內(nèi)容完全可以由 XSS 說(shuō)了算。不論什么登錄框、框架頁(yè)，甚至安全插件，我們都可以將其刪除，用看起來(lái)完全相同的文本框代替。得到賬號(hào)后，通過(guò)后臺(tái)反向代理實(shí)現(xiàn)登錄，然后通知前端腳本偽造一個(gè)登錄成功的界面。
所以，HTTPS 被用在 HTTP 頁(yè)面里，意義就大幅下降了。
和『緩存投毒』配合出擊
在流量劫持第二篇里提到『HTTP 緩存投毒』這一概念，只要流量暫時(shí)性的被劫持，都可導(dǎo)致緩存長(zhǎng)期感染。但這種攻擊有個(gè)前提，必須事先找到站點(diǎn)下較穩(wěn)定的腳本資源，做投毒的對(duì)象。
傳統(tǒng)登錄
在傳統(tǒng)的登錄模式里，緩存投毒非常難以利用：
HTTPS 資源顯然無(wú)法被感染。
而使用 HTTPS 向下轉(zhuǎn)型的方案，也會(huì)因?yàn)殡x開(kāi)劫持環(huán)境，而無(wú)法訪問(wèn)中間人的 HTTP 版登陸頁(yè)面，導(dǎo)致緩存失效；或者這個(gè)真實(shí)的 HTTP 版的登錄頁(yè)面根本就不接受你的本地緩存，直接重定向到正常的 HTTPS 頁(yè)面。
因此只有在主頁(yè)面上，修改鏈接地址，讓用戶跳轉(zhuǎn)到釣魚(yú)網(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ù)。
接著開(kāi)啟我們的釣魚(yú)熱點(diǎn)，讓前來(lái)連接的用戶，訪問(wèn)任何一個(gè)頁(yè)面都能中毒。
為了讓釣魚(yú)熱點(diǎn)更隱蔽，這次我們不再使用路由器，而是利用報(bào)廢的安卓手機(jī)（下一篇文章詳細(xì)講解如何實(shí)現(xiàn)）。
為了不影響附近辦公，本文就不演示同名熱點(diǎn)釣魚(yú)了，所以隨便取了個(gè)名字。
接著讓『受害者』來(lái)連一下我們的熱點(diǎn)：
之前正好開(kāi)著網(wǎng)頁(yè)，所以很快收到了 HTTP 請(qǐng)求。我們?cè)谌魏尉W(wǎng)頁(yè)里注入 XSS，進(jìn)行緩存投毒。
（由于原理和之前講一樣，所以這里就省略步驟了）
然后重啟電腦，連上正常的 WiFi（模擬用戶回到安全的場(chǎng)合）。
打開(kāi) tiebai.baidu.com，一切正常。
開(kāi)始登錄了。。。
看看這種浮層登錄框，能否躲避我們的從沉睡中喚起的 XSS 腳本：
奇跡依然發(fā)生！
由于之前有過(guò)詳細(xì)的原理講解，因此這里就不再累述了。不過(guò)在實(shí)戰(zhàn)中，緩存投毒+非安全頁(yè)面登錄框，是批量獲取明文賬號(hào)的最理想手段。
不可逆的記憶
如果現(xiàn)在再將登錄模式換回傳統(tǒng)的，還來(lái)得及嗎？顯然，為時(shí)已晚。
當(dāng)網(wǎng)站第一次從傳統(tǒng)登錄，升級(jí)到浮層登錄時(shí)，用戶大多不會(huì)立即輸入，而是『欣賞』下這個(gè)新版本的創(chuàng)意。確認(rèn)不是病毒廣告彈出的窗口，而是真的官方設(shè)計(jì)的，才開(kāi)始登錄。
當(dāng)用戶多次使用浮層登錄框之后，慢慢也就接受了這種新模式。
即使未來(lái)，網(wǎng)站取消了浮層登錄，黑客使用 XSS 創(chuàng)建一個(gè)類似的浮層，用戶仍會(huì)毫不猶豫的輸入賬號(hào)。因?yàn)樵谒麄兊挠洃浝铮俜骄驮褂眠^(guò)，仍然保留著對(duì)其信任度。
安全性升級(jí)
既然這個(gè)過(guò)程是不可逆的，撤回傳統(tǒng)模式意義也不大。事實(shí)上，使用浮層的用戶體驗(yàn)還是不錯(cuò)的，對(duì)于不了解安全性的用戶來(lái)說(shuō)，還是喜歡華麗的界面。
要保留體驗(yàn)，又得考慮安全性，最好的解決方案就是將所有的頁(yè)面都使用 HTTPS，將站點(diǎn)武裝到牙齒，不留一絲安全縫隙。這也是未來(lái)網(wǎng)站的趨勢(shì)。
it知識(shí)庫(kù)：流量劫持——浮層登錄框的隱患，轉(zhuǎn)載需保留來(lái)源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。
