【51CTO.com專欄稿件】回顧近幾年國內發生的各類惡意劫持事件中，莫過于通信運營商的流量劫持，該行為嚴重干擾到了個人和企業用戶的正常使用和運營。鑒于互聯網上已經有大量關于此類攻擊的案例分析和闡述，為了更加有效的防御此類攻擊，本文將換一個角度思考和分析，以劫持攻擊者的立場，通過具體的劫持實驗來簡述過程。

目前國內做運營商劫持的主要模式，即通過旁路分光設備鏡像流量，并監聽用戶HTTP GET上行請求，篡改正常返回的信息，從而實現隱蔽的劫持互聯網網站信息。因劫持手法種類多樣，限于篇幅，本文將只采用其中一種劫持第三方js代碼的方式來進行闡述。

一、劫持演示準備

1、獲取互聯網用戶發往80端口的網絡數據包，無需回傳的數據包。

2、演示用戶的瀏覽器使用基數和安全程度較高的Chrome。經過筆者測試，該演示方案對于Windows系統 +其他瀏覽器的組合，以及移動端iPhone和Android平臺上的默認瀏覽器均有效。

3、注冊開通某商網站聯盟賬號，系統會從后臺分配到一個可跳轉的url，該url會給用戶設置 cookie，同時用做系統后期統計計費分成。

例如申請到的url如下：

http://u.XXX.com/union/XXXRedirect.aspx?TypeID=2&Allianceid=1234&sid=56789&OUID=abc&jumpUrl=http://www.XXX.com

紅色字體為不同的加盟賬戶被分配的不同編號，若該參數被惡意篡改，該用戶推廣獲得的收入分成將轉移。

用curl命令請求該鏈接，將獲得如下圖中返回包的截圖。其中紅色部分標明了該返回包進行了Set-Cookie計費和跳轉操作。

二、劫持過程簡述

1、 當用戶訪問www.XXX.com，同時劫持者旁路偵聽到該用戶瀏覽器請求了某第三方js代碼。(本文將拿Google Analytics的統計代碼ga.js 來舉例，完整鏈接：www.google-analytics.com/ga.js)，Referer 目標站www.XXX.com。

2、 先于www.XXX.com的服務器返回構造過的TCP包給用戶，同時將篡改過的ga.js代碼返回。

篡改過的ga.js代碼，詳見下面截圖：

3、劫持完成后用戶瀏覽器的訪問不會有明顯的異常感知，打開chrome的開發者工具查看訪問情況，如下截圖：

在用戶的主機上打開wireshark 做抓包分析，可以看到被我方強制植入的統計Cookie已經成功，效果如下截圖：

三、該類js劫持的特點

1、 該類js代碼是由第三方發布和更新，正常情況下不會有人對其返回進行校驗。即便用戶頻繁重復請求或者請求失敗，被劫持方不會被主動告知。

2、 操作隱蔽且靈活，通過多種方式只需發送1k以下的數據包篡改js代碼，即可完成劫持，無需額外的服務器再做跳轉。

3、 該類js代碼在國內中小型web站點甚至大型網站具有較高的使用率，比如本文中提到的ga.js通常用作網站流量統計實現。

四、排查和防御方式

1、 目前最流行的運營商劫持方式，即直接在用戶訪問www.XXX.com的時候對其訪問劫持，并直接302重定向跳轉到預先設定好的url鏈接上，此類方式較易被發現，目前國內大多數web站點均開啟了https加密策略，可以部分有效的防御此種劫持攻擊。

2、 對用戶瀏覽器側的js代碼進行校驗，并對CDN節點上的緩存內容做定時輪訓匹配對比，判斷是否被篡改。監控用戶真實得到的web源代碼，觀察是否被非法注入或者強制跳轉等等。

3、 因該類劫持攻擊需要在真實服務器返回的TCP包到達前，就將偽造包發到用戶瀏覽器，否則將失去效果。因此排查此類攻擊方式應遵從，優先從用戶側排查，也可采用判斷TTL不同返回值來做劫持層定位。

4、 通信運營商應該加強自身內部人員和設備管理，并在節點配置部署URPF策略，將偽造IP頭的包全部丟棄。比如，排查在關鍵回寫植入點的路由器上的ACL規則，拒絕放行特殊格式或者特征的回寫包。

【本文是51CTO專欄機構作者“數字觀星技術組”的原創文章，轉載請聯系原作者】