流量劫持——浮層登錄框的隱患

>>>  技術話題—商業文明的嶄新時代  >>> 簡體     傳統

  傳統的登錄框

  在之前的文章流量劫持危害詳細講解了 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,將站點武裝到牙齒,不留一絲安全縫隙。這也是未來網站的趨勢。


網載 2014-07-04 08:39:14

[新一篇] 谷歌服務全線被封 [六州歌頭] 文/流水弦歌

[舊一篇] App Store上推廣App的實戰經驗
回頂部
寫評論


評論集


暫無評論。

稱謂:

内容:

驗證:


返回列表