傳統(tǒng)的登錄框

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

 

 

這是最經典的登錄模式。盡管主頁面并沒有開啟 HTTPS，但登錄時會跳轉到一個安全頁面來進行，所以整個過程仍是比較安全的 —— 至少在登錄頁面是安全的。

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

 

 

其中轉型 HTTPS 的手段最為先進，甚至一些安全意識較強的用戶也時有疏忽。

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

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

 

 

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

華麗的登錄框

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

然而華麗的背后，其本質仍是一個網頁，自然掩蓋不了網頁的安全缺陷。

當網頁特效蔓延到一些重要數據的交互 —— 例如賬號登錄時，風險也隨之產生。因為它改變了用戶的使用習慣，同時也徹底顛覆了傳統(tǒng)的意識。

 

 

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

HTTP 頁面用 HTTPS 有意義嗎?

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

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

使用 HTTPS 確實能保障通信的安全。但在這個場合里，它只能保障『發(fā)送』的數據，對于『接收』的流量，則完全不在其保護范圍內。

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

 

 

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

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

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

和『緩存投毒』配合出擊

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

傳統(tǒng)登錄

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

HTTPS 資源顯然無法被感染。

而使用 HTTPS 向下轉型的方案，也會因為離開劫持環(huán)境，而無法訪問中間人的 HTTP 版登陸頁面，導致緩存失效;或者這個真實的 HTTP 版的登錄頁面根本就不接受你的本地緩存，直接重定向到正常的 HTTPS 頁面。

因此只有在主頁面上，修改鏈接地址，讓用戶跳轉到釣魚網站去登錄，才能勉強利用。

浮層登錄

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

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

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

盡管這種登錄模式風險重重，但最近百度也升級成浮層登錄框，并且還是所有產品。所以，我們再次嘗試那套的古老方法，看看在如今是否仍能發(fā)起攻擊。

我們選幾個最常用的產品線，進行一次緩存掃描：

 

 

果然，每個產品線里都有長期未修改、并且緩存很久的腳本庫。

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

為了讓釣魚熱點更隱蔽，這次我們不再使用路由器，而是利用報廢的安卓手機(下一篇文章詳細講解如何實現)。

 

 

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

接著讓『受害者』來連一下我們的熱點：

 

 

之前正好開著網頁，所以很快收到了 HTTP 請求。我們在任何網頁里注入 XSS，進行緩存投毒。

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

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

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

 

 

開始登錄了。。。

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

 

 

奇跡依然發(fā)生!

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

不可逆的記憶

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

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

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

即使未來，網站取消了浮層登錄，黑客使用 XSS 創(chuàng)建一個類似的浮層，用戶仍會毫不猶豫的輸入賬號。因為在他們的記憶里，官方就曾使用過，仍然保留著對其信任度。

安全性升級

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

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