lk1ngaa7 · 2015/12/29 10:53
最近在處理了一些http劫持的案例和拜讀業內不少大牛的文章之後，覺得有必要把最近的一些關於劫持案例的分析和思考記錄下來，以留作日後備忘。
首先是一例典型的旁路劫持案例：
劫持者應該是利用在運營商內部的便利條件，在閘道器路由器上新增嗅探程式，嗅探明文http請求資料報，拿到要劫持的資料報之後，馬上給請求者返回http response（302 到其他 url），並且立即關閉當前http 請求。劫持者 302 的 url 是原**的乙個計費請求，類似**推廣鏈結，但是比較讓人鬱悶的是，劫持者返回的資料報是兩個 tcp 資料報，偶爾會出現 tcp 報亂序（劫持技術不過關），導致客戶端無法識別，從而導致頁面白屏，嚴重影響使用者體驗 ！
下面介紹一下我是如何從資料報分析和定位劫持路由的：
頁面請求後得到奇怪資料返回：
請求中 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定義：
但是在這次連線中，劫持者的 identification 等於被劫持的 identification：
劫持者：
被劫持者：
仔細看，可以發現 993 和 1022 這兩個包的identification 是一樣的，多次抓包也是這樣，所以這裡可以判斷，鏈路上肯定出了問題。
從這以上兩個特徵，基本上可以得出結論：
劫持者提前給瀏覽器返回了響應，且關閉了 http 連線。導致正確的 資料報沒有被接受，使得瀏覽器發生了異常跳轉。而使用者頁面出現白屏的情況是劫持失敗，劫持者的資料報亂序（程式錯誤），導致應用層無法獲得爭取 http 響應。
劫持過程應該類似於：
結論已經獲得，但是問題的解決就是要定位到相應的劫持路由，然後向有關部門反饋：
如果出現一定數量的使用者反饋，可以多聯絡幾位使用者（不同網路環境下，能復現劫持），抓包，然後獲取 trace 截圖，如果他們出現某幾跳路由的重複，就可以縮小定位範圍，或者直接定位路由ip。
根據劫持包的ttl反推，用 scapy 來構造自定義的，可以復現劫持的http請求包，然後以 ttl 從 1 開始遞增發包，出現劫持響應時，可以判斷劫持者的位置。
也談武媚娘
前段時間電視熱播 武媚娘 老婆天天晚上看。我不大喜歡看各種誇張和粉飾的歷史劇，但是對歷史還是喜歡一些，所以就利用閒餘的時間搜尋一下，看看唐朝的那些事。正好把自己的搜尋和感慨整理記錄下。唐朝是乙個中國發展的乙個鼎盛時期，即便如此，也是乙個多事的朝代。李世民宣武門弒兄，自己逼迫父親成為了太上皇，兒子李志...
也談介面程式設計
剛剛和大峽討論乙個問題，介面程式設計，這個話題也許大家比我理解多了，我提出乙個自己的觀點 在個人程式中空介面很少，至少我見的很少！大峽 不對，空介面很多，介面只不過是乙個標識,然後我們做了乙個很有意思的程式 空介面 package springroad.demo.taginte ce public ...
也談大數階乘
最近公司裡面的專案一直用c 來進行，基礎太薄弱，於是自己完成了公司的任務後，加緊練習。本來那天是想寫乙個遞迴階乘演算法的，發現有不少問題啊 第一 遞迴有乙個弊端，就是棧空間不夠的問題 第二 遇到大數的時候，在cpp中沒有辦法找到合適的資料型別來進行計算，用long，double都是不可能夠的。因為我...