上一篇文章，介紹了常見的流量劫持途徑。然而無論用何種方式獲得流量，只有加以利用才能發揮作用。

不同的劫持方式，獲得的流量也有所差異。DNS 劫持，只能截獲通過域名發起的流量，直接使用 IP 地址的通信則不受影響;CDN 入侵，只有瀏覽網頁或下載時才有風險，其他場合則毫無問題;而網關被劫持，用戶所有流量都難逃魔掌。

在本文中，我們通過技術原理，講解如下問題：

- 為什么喜歡劫持網頁?
- 只瀏覽不登陸就沒事嗎?
- 自動填寫表單有風險嗎?
- 離開劫持環境還受影響嗎?
- 使用 HTTPS 能否避免劫持?
- 流量劫持能否控制我電腦?

為什么喜歡劫持網頁?

理論上說，劫持到用戶的流量數據，也就獲得相應程序的網絡通信。但在現實中，數據并不代表真實內容。一些重要的網絡程序，都是私有的二進制協議，以及各種加密方式。想通過流量來還原出用戶的聊天信息、支付密碼，幾乎是不可能的。即使花費各種手段，破解出某個程序的通信協議，然而一旦程序升級改變了協議格式，或許就前功盡棄了。因此，很難找到種一勞永逸的客戶端劫持方案。

然而，并非所有程序都是客戶端的。一種新興的應用模式 —— WebApp，發展是如此之快，以至于超越客戶端之勢。在如今這個講究跨平臺、體驗好，并有云端支持的年代，WebApp 越來越火熱。各種應用紛紛移植成網頁版，一些甚至替代了客戶端。同時，也造就了流量劫持前所未有的勢頭。

WebApp，其本質仍是普通的網頁而已。盡管網頁技術在近些年里有了很大的發展，各種新功能一再增加，但其底層協議始終沒有太大的改進 —— HTTP，一種使用了 20 多年古老協議。

在 HTTP 里，一切都是明文傳輸的，流量在途中可隨心所欲的被控制。傳統程序事先已下至本地，運行時只有通信流量;而在線使用的 WebApp，流量里既有通信數據，又有程序的界面和代碼，劫持簡直輕而易舉。

上一篇也提到，如果在戶外沒有 3G 信號的地方釣魚，無法將獲得的流量轉發到外網。然而，使用網頁這一切就迎刃而解。我們完全可以在自己的設備上搭建一個站點，留住用戶發起離線攻擊。對于那些連上 WiFi 能自動彈網頁的設備，那就更容易入侵了。

因此，劫持網頁流量成了各路黑客們的鐘愛，一種可在任意網頁發起 XSS 的入侵方式。 

下面，開始我們的攻防之旅。#p#

只瀏覽不登陸就沒事嗎?

每當磚家出來提醒時，總免不了這么一句：公共場合盡量不登錄賬號。于是，大家就認為只看網頁不登陸就平安無事了。

如果是公共的電腦，那也就無所謂;否則，自己的一些賬號可能就倒霉了。

在自己的設備上，大家都會記住各種賬號的登錄狀態，反正只有自己用，也沒什么大不了的。然而，在被劫持的網絡里，一切皆有可能發生。即使瀏覽再平常不過的網頁，或許一個悄無聲息的間諜腳本已暗藏其中，正偷偷訪問你那登錄著的網頁，操控起你的賬號了。

聽起來似乎很玄乎吧，磚家似乎也沒說已登錄的賬號會怎么樣。難道隨便一個網頁，就能讓各種賬號被控制嗎?

大家都知道，HTTP 是無狀態的，不像傳統協議有個『會話』之類的概念。各種賬號的登錄狀態，只能依靠瀏覽器的 Cookie 來實現。因此，只要有了的 Cookie 也就獲得了用戶賬號的使用權。

和傳統 XSS 攻擊不同，流量劫持可以得到任何通信數據，當然也包括那些受 HttpOnly 保護的 Cookie。攻擊腳本只需對某個站點發起請求，黑客即可在中途劫持到傳輸的 Cookie 數據。如果同時發起眾多站點，就能覆蓋相當一部分目標了。

這種請求未必要真正訪問一次頁面，僅僅將 URL 作為圖片加載，將目標站點的 Cookie 送出即可。

黑客得到 Cookie，即可在自己瀏覽器里還原出登錄狀態。盡管你確實沒有登錄操作，但那些已登錄的卻能出賣你。

防范措施：

訪問一些重要的網站，盡量不要記住登錄狀態，以免 Cookie 被泄露。不過，只要網站綁定了 Cookie 和 IP 段，這招的危害程度就大幅降低了，僅憑 HttpOnly 還是很不靠譜的。#p#

自動填寫表單有風險嗎?

使用上面的方法獲得 Cookie，即使能控制賬號，但其密碼仍無法得知，隨時都有可能失去控制權。

不過，一些用戶有讓瀏覽器自動保存密碼的習慣。通過這點，我們是否能套出記住的密碼來呢?

分析下瀏覽器是如何自動填寫頁面表單的。其實很簡單，瀏覽器發現頁面 URL 和表單名匹配記錄里的，就自動填上了。

要是在流量可控的網絡里，剝離頁面所有內容只剩表單，又會如何?

保存著的密碼仍能自動填上，并且可被腳本訪問到!

如果我們在用戶訪問的頁面里，創建大量的隱藏框架頁，即可嘗試獲取各種網站保存著的賬號了。(不過如今 Chrome 框架頁已經不會自動填寫了。具體實現和瀏覽器有關)。

不過，即使框架頁不自動填寫，但主頁面總得保留該功能吧。如果發現用戶某個打開著的網頁很久沒有交互了，可悄悄跳轉到如上那樣的純表單頁，無論能否獲取數據，都將繼續跳轉，一個接一個的嘗試。。。直到用戶切回窗口，再恢復到原先那個頁面。

由于泄露的是明文的賬號和密碼，即使數量不多，也能通過社工獲取到用戶的更多信息，最終導致更嚴重的泄露。

防范措施：

所以無論是 Cookie 記住登錄，還是瀏覽器自動填表，重要的賬號都應慎用。

瀏覽器的自動填表也應增加些安全策略，例如必須有用戶的交互才開始填寫，規定的時間里只能填有限次。#p#

離開劫持環境還受影響嗎?

或許你在想，網絡再怎么不安全，離開之后就應該沒事了吧。

有時在公共場合趕上免費的 WiFi，打開網頁看一會新聞，是常有的事。這么短的時間里能有多大的事。不過在入侵腳本面前，一小會和長久并沒太大區別。機會只要出現了，無論多么短暫都能滲透。

如果只看重眼前利益，這種短暫的入侵并沒多少利用價值;但若放遠目光，能讓攻擊在今后發起，那就不再局限于時間和空間了。因此，我們需要一個時光機，讓入侵腳本穿越到用戶未來的時空運行。

若用傳統 XSS 的思維，這幾乎無法實現。但在流量劫持面前，一切皆有可能 —— 因為我們能控制任意流量!

HTTP 緩存投毒

上一篇文章提到，但凡有緩存的地方都是大有可為的。顯然，對于有著復雜的 HTTP 緩存系統來說，存在缺陷是在所難免了。這種簡單的純文本協議，幾乎沒有一種簽名機制，來驗證內容的真實性。即使頁面被篡改了，瀏覽器也完全無法得知，甚至連同注入的腳本也一塊緩存起來。

于是，我們可以將『緩存投毒』的概念，引入 HTTP 協議里。但凡具備可執行的資源，都可以通過預加載帶毒的版本，將其提前緩存起來。

為了將緩存的有效期發揮到極致，我們事先在各大網站上，找出一些過期時間長、很久沒有修改的資源，評估其未來變化不大的可能。

當用戶打開任意一個 HTTP 網頁時，注入的 XSS 代碼開始預加載這些資源。由于一切流量都在控制之中，我們可以完全不走代理，而是返回自己的攻擊腳本。

 

用戶瀏覽器收到回復后，就將其一一緩存起來了。我們可以事先收集大量的資源地址，讓用戶在線的時間里，盡可能多的緩存受到感染。

未來，用戶訪問引用了這些資源的網站時，入侵腳本將穿越時空，從沉睡中喚醒。

只要用戶不清空緩存，這些被感染的腳本始終附著在瀏覽器緩存里，直到用戶強制刷新頁面時或許才能解脫。更多細節可參考這里。

離線儲存投毒

不過，有些網站使用的都是很短的緩存，上述的入侵方式似乎就無能為力了。不過，HTML5 時代帶來了一項新的緩存技術 —— 離線儲存。由于它沒有過期時間，因此適用于任意網頁的投毒!

類似的，當用戶觸發了我們的注入腳本之后，我們創建一個隱形的框架頁，加載被感染的網頁。同樣，通過流量劫持，我們返回一個簡單的頁面，里面包含一個帶有 manifest 屬性的 HTML 文檔，以及后期運行的腳本。

由于通過隱藏框架訪問了這個頁面，用戶并不知情，但盡職的瀏覽器卻將其緩存起來。

未來，用戶打開被感染的網頁時，瀏覽器直接從離線儲存里取出，其中布置的腳本因此觸發。

由于是個空白頁面，因此需要填充上真實的網站內容。最簡單的方法，就是嵌套一個原頁面的框架，并在 URL 里加上隨機數，確保是最新的在線內容。

因為嵌套的是同域框架，最終仍能被入侵腳本所控制。

不過，離線存儲投毒的后期影響會小一些。未來用戶在安全的網絡里打開頁面時，瀏覽器會再次請求 .appcache 文件。由于這個文件并不一定存在，因此瀏覽器很可能刪除掉離線數據。

理論上說只有一次的觸發機會，但它沒有過期時間，適用于任意 HTTP 頁面投毒。

防范措施：

在不安全的場合，盡量使用『隱身模式』瀏覽網頁。例如 Chrome 里按 Ctrl+Shift+N 就能調出，可將自己處于隔離的沙盒里。

FireFox 瀏覽器存儲離線文件時，會有用戶交互提示，提醒用戶是否有這必要。

也許不久后，框架頁面不再被離線儲存所接受，新標準隨時都有可能改變。但 HTTP 緩存投毒是協議棧的缺陷，因此很難防范，下一篇會發現實際入侵效果非常理想。#p#

使用HTTPS能否避免劫持?

如果從密碼學的角度來說，使用了 SSL 加密的數據確實難以破解，更不用談修改了。

然而，惹不起但總躲得起吧。雖然無法破解，但流量仍掌握在自己手中，走哪條路還是由我說的算，完全可以繞過你。

偷換證書

不同于簡單的 HTTP 代理，HTTPS 服務需要一個權威機構認定的證書才算有效。自己隨便簽發的證書，顯然是沒有說服力的，HTTPS 客戶端因此會質疑。

在過去，這并不怎么影響使用過程，無非彈出一個無效的證書之類的提示框。大多用戶并不明白是什么情況，就點了繼續，導致允許了黑客的偽證書，HTTPS 流量因此遭到劫持。

在經歷越來越多的入侵事件之后，人們逐漸意識到，不能再輕易的讓用戶接受不信任的證書了。如今，主流瀏覽器對此都會給予嚴重的警告提示，避免用戶進入偽安全站點。

如果重要的賬戶網站遇到這種情況，無論如何都不該繼續，否則大門鑰匙或許就落入黑客之手。

因此，這種偷換證書的劫持，在安全意識越來越高的今天，很難再發揮實效了。我們需要一個更隱蔽的方式來躲開加密數據。

過濾 HTTPS 跳轉

事實上，在 PC 端上網很少有直接進入 HTTPS 網站的。例如支付寶網站，大多是從淘寶跳轉過來，而淘寶使用的仍是不安全的 HTTP 協議。如果在淘寶網的頁面里注入 XSS，屏蔽對 HTTPS 的頁面訪問，用 HTTP 取而代之，那么用戶也就永遠無法進入安全站點了。

盡管地址欄里沒有出現 HTTPS 的字樣，但域名看起來也是正確的，大多用戶都會認為不是釣魚網站，因此也就忽視了。

因此，只要入口頁是不安全的，那么之后的頁面再安全也無濟于事。

當然也有一些用戶通過輸網址訪問的，他們輸入了 www.alipaly.com 就敲回車進入了。然而，瀏覽器并不知道這是一個 HTTPS 的站點，于是使用默認的 HTTP 去訪問。不過這個 HTTP 版的支付寶的確也存在，其唯一功能就是重定向到自己HTTPS站點上。

劫持流量的中間人一旦發現有重定向到 HTTPS 站點的，顯然不愿意讓用戶走這條不受自己控制的路。于是攔下重定向的命令，自己去獲取重定向后的站點內容，然后再回復給用戶。于是，用戶始終都是在 HTTP 站點上訪問，自然就可以無限劫持了。

搜索引擎劫持

事實上，HTTPS 站點還有個很大的來源 —— 搜索引擎。遺憾的是，國產搜索引擎幾乎都不提供 HTTPS 服務。因此在不安全的網絡里，搜索結果是不具備任何權威的。

防范措施：

重要的網站必定使用 HTTPS 協議，登陸時需格外留意。

國外的大型網站幾乎都提供 HTTPS 服務，甚至是默認的標準。相比國內只有少數重要的服務才使用，絕大多數的信息都是在明文傳輸。這是為了方便什么來著，你猜。#p#

流量劫持能否控制我電腦?

如果不考慮一些瀏覽器安全漏洞，理論上說網頁與系統是完全隔離的，因此無需擔心系統受到影響。

釣魚插件

有時為了能讓網頁獲得更多的在線能力，安裝插件必不可少，例如支付控件、在線播放器等等。在方便使用的同時，也埋下了安全隱患。

如果是一些小網站強迫用戶安裝插件的，大家幾乎都是置之不理。但若一些正規的大網站，提示用戶缺少某些插件，并且配上一些專業的提示，相信大多都會選擇安裝。而這一切，通過被注入的攻擊腳本完全能辦到。

不過，正規的插件都是有完整的數字簽名的，而偽造的很難躲過瀏覽器的驗證，會出現各種安全提示。因此，攻擊者往往使用直接下載的方式，提示用戶保存并打開安裝包。

頁面提權

現在越來越多的應用程序，選擇使用內嵌網頁來簡化界面的開發，在移動設備上更是普遍。

通常為了能讓頁面和客戶端交互，賦予一些本地程序的接口供調用，因此具有了較高的權限。不過，正常情況下嵌入的都是受白名單限制的可信頁面，因此不存在安全隱患。

然而在被劫持的網絡里，一切明文傳輸的數據都不再具備可信度。同樣的腳本注入，就能獲得額外的權限了。

一些帶有缺陷的系統，攻擊腳本甚至能獲得出乎意料的能力。通過之前提到的網頁緩存投毒，這顆埋下的地雷隨時都有可能觸發。

下載程序

即使上網從不安裝插件，但是下載程序還是經常需要的。由于大多數的下載網站，使用的都是 HTTP 流量，因此劫持者能輕易的修改可執行文件，將其感染上病毒或木馬，甚至完全替換成另一個程序。

用戶總認為從官網上下載的肯定沒問題，于是就毫無顧慮的打開了。這時，入侵的不再是瀏覽器環境，而是能控制整個系統了。

防范措施：

如果是從瀏覽器里下載的程序，留意是否具有數字簽名，正規的廠商幾乎都會提供。如果想試用一些來路不明的小程序，保存到虛擬機里使用就放心多了。

未來 SPDY 技術普及的時候，就再不用擔心網頁劫持這些事。它將 HTTP 協議封裝在加密的流量里傳輸，想劫持一個普通網頁都很困難了。

結尾

暫時就說到這。事實上類似 XSS 的攻擊方式還有很多，這里只談了一些能和流量劫持配合使用的。利用上一篇講述的各種劫持途徑，配合本文提到的入侵方式，可以劫持不少用戶了。下一篇，將演示如何利用這些原理，發起實戰攻擊。

原文鏈接：http://fex.baidu.com/blog/2014/04/traffic-hijack-2/