最近在處理了一些HTTP劫持的案例和拜讀業內不少大牛的文章之后，覺得有必要把最近的一些關于劫持案例的分析和思考記錄下來，以留作日后備忘。
首先是一例典型的旁路劫持案例：
劫持者應該是利用在運營商內部的便利條件，在網關路由器上添加嗅探程序，嗅探明文HTTP請求數據包，拿到要劫持的數據包之后，馬上給請求者返回HTTP response（302 到其他 url），并且立即關閉當前HTTP 請求。劫持者 302 的 url 是原網站的一個計費請求，類似淘寶推廣鏈接，但是比較讓人郁悶的是，劫持者返回的數據包是兩個 TCP 數據包，偶爾會出現 TCP 報亂序（劫持技術不過關），導致客戶端無法識別，從而導致頁面白屏，嚴重影響用戶體驗 ！
下面介紹一下我是如何從數據包分析和定位劫持路由的：
case 背景：山西移動部分地區，訪問國內頂級中文導航網站出現白屏現象。
頁面請求后得到奇怪數據返回：
請求中 Connection 字段為 keep alive 且請求協議是 1.0 而返回的header 關閉了請求，返回一段奇怪的js，跳轉到另外一個 url
接下來觀察 TCP flow：
這次TCP 連接上有 3 個奇怪的現象，都可以證明這是一次處于鏈路中的劫持，之后如果遇到類似的情況也可以從這三個方面入手來處理：
server 給 client 的 TCP 報的 TTL 不一致，且抖動很大。
server 給 client 的 IP identification，出現不符合 RFC 標準的情況
客戶端接受的數據包TTL是 51 ，后面來自真實 server 的TTL 是 47，還有 1022 和 1024（本來應該在前面） 都是兩個來自 劫持者的數據包，但是 fin 包在前，提前關閉連接，導致HTTP應用層拿不到正確的數據，導致瀏覽器白屏。
這次 TCP 連接上的其他數據包，可以看到有 部分 數據包，被拋棄，而且被拋棄的數據包的 TTL 和 握手包的TTL 相等（一般 握手包 不會被劫持，說明被拋棄的包是來自 真實的服務器的）是 47 。
RFC定義：
所以對于給定地址和協議的 ip 包來說，它的identification應該是公差為 1 的單調遞增數列：
但是在這次連接中，劫持者的 identification 等于被劫持的 identification：
劫持者：
被劫持者：
仔細看，可以發現 993 和 1022 這兩個包的identification 是一樣的，多次抓包也是這樣，所以這里可以判斷，鏈路上肯定出了問題。
從這以上兩個特征，基本上可以得出結論：
劫持者提前給瀏覽器返回了響應，且關閉了 HTTP 連接。導致正確的 數據包沒有被接受，使得瀏覽器發生了異常跳轉。而用戶頁面出現白屏的情況是劫持失敗，劫持者的數據包亂序（程序錯誤），導致應用層無法獲得爭取 HTTP 響應。
劫持過程應該類似于：
結論已經獲得，但是問題的解決就是要定位到相應的劫持路由，然后向有關部門反饋：
定位的方法我推薦幾種：
?如果出現一定數量的用戶反饋，可以多聯系幾位用戶（不同網路環境下，能復現劫持），抓包，然后獲取 trace 截圖，如果他們出現某幾跳路由的重復，就可以縮小定位范圍，或者直接定位路由IP。
根據劫持包的TTL反推，用 scapy 來構造自定義的，可以復現劫持的HTTP請求包，然后以 TTL 從 1 開始遞增發包，出現劫持響應時，可以判斷劫持者的位置。
謝謝這兩篇文章的作者，指定迷津