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