日常遇到的劫持一般為DNS劫持，可在路由器里強制指定公共DNS解決。本文記錄了自己家用寬帶HTTP劫持的發現過程。相比DNS劫持，HTTP劫持則更為流氓，解決起來也比較棘手。

近來在家上網時，iPhone Safari網頁里經常彈出“在手機淘寶中打開連接嗎？”的提示框，如下圖：

作為一名iOS碼農，很自然的知道這是網頁在調用淘寶app的 URL Scheme tbopen:// ，這是干什么的呢？當然是淘寶客的推廣鏈接，點了之后打開淘寶去領券，如果你按提示下單了，推廣者就能拿到返利。問題在于，網頁為什么會發出這種請求，結合當前網站是http的，隱隱覺得可能是被劫持了。下面記錄一下排查過程。

誰在劫持

先說一下環境，家里寬帶是聯通百兆，路由器華碩AC86U,刷的梅林（僅開啟虛擬內存插件），路由器直接撥號，且當時安裝條件限制，家里沒有光貓，接線員直接接到了一樓的交換機上。

1. 是網站自己掛的廣告嗎？

在Wi-Fi下，每次用Safari隱身模式反復訪問截圖里這個網站，仍會出現這個提示，概率大概30%-40%。切換手機聯通4G網絡，移動4G，則一次都不會出現。換用電腦Safari和Chrome，也一次不會出現。

結論：僅在iPhone手機端Wi-Fi環境才會出現

2. 是路由器刷的梅林固件導致的嗎？

翻箱倒柜找出了以前買的 TPLink-WR700n，就是下圖這個小路由器（簡直是神器，小巧玲瓏，AP和Router模式任意切換），設置好撥號賬號密碼后換掉華碩繼續測試，震驚了，劫持彈窗仍然存在。

[[324678]]

結論：梅林沒問題，只能是運營商的鍋了。

怎樣劫持

由于梅林里已經設置DNS為114，排除了DNS劫持。確定是運營商的接入點的問題，接下來就是看看它究竟是怎么劫持的。這里使用Charles抓包iPhone（還沒必要祭出Wireshark大殺器）具體設置不在這里講了，在百度里隨機訪問網頁，待出現劫持時，停止記錄，開始分析記錄日志。從后往前，找出返回數據里包含 tbopen 的請求。不出意外，很容易就發現了：

原請求為 http://static.geetest.com/static/js/fullpage.8.9.3.js ，經過確認， https://www.geetest.com/ 極驗，是業界提供安全與風控解決方案的平臺，不可能返回 tbopen 這樣的數據的。在Charles里復制此http請求的curl命令出來，使用阿里云VPS里進行訪問，獲取到的則為真實的JS內容。

curl -H 'Host: static.geetest.com' -H 'Accept: */*' -H 'User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 12_1_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0 Mobile/15E148 Safari/604.1' -H 'Accept-Language: zh-cn' -H 'Referer:<a href="http://pass.52pk.com/">http://pass.52pk.com/</a>' --compressed '<a href="http://static.geetest.com/static/js/fullpage.8.9.3.js">http://static.geetest.com/static/js/fullpage.8.9.3.js</a>' 

使用自己的Mac重放這個curl命令，還是有很高幾率被劫持。進一步，修改此請求的User-Agent字段，去掉手機標識符，僅保留為Safari，繼續重放，則不會出現被劫持。同時，注意到發生劫持后，有個新的同樣的js請求發出，url里多了個參數utm_id=1024001，會返回正確的JS內容，這樣做的目的，猜測可能是為了區分請求，好讓真正的JS能正常返回不影響網頁加載，否則可能出現劫持后再被劫持，無法加載出正確的JS內容。

至此，整個劫持的過程大致清晰了：聯通的接入點會根據UA過濾出移動設備中的http JS請求，然后一定幾率返回劫持后的偽JS內容，在里面嵌入淘寶客推廣鏈接。

劫持的JS內容如下，里面有淘寶客推廣鏈接，建議阿里媽媽的相關人士解決一下？

代碼比較簡單，將自己的JS腳本掛載到頁面DOM上，使用setInterval延遲20ms去調用tbopen，打開淘寶app領券。

想在手機端暫時屏蔽的話，可以在surge里加個Header Rewrite規則修改UA

[Header Rewrite] 
^http://* header-replace User-Agent Safari/530 

投訴

用手機錄屏兩段視頻作為證據，先打聯通客服投訴電話，客服按套路說會派人來檢查。一天過后回電說檢修人員說是客戶家里問題，無法解決。 ？？？根本沒人聯系我，且上門檢查。沒關系，心平氣和的告訴客服小妹，你們解決不了那俺只能向上投訴了。這里不用跟客服急眼，先向運營商投訴本來也不指望他們能馬上解決，該走的流程還是得走一下。找到省通信管理局網站，留言說明了情況，第二天臨下班前就有回訪電話，把自己錄的視頻作為證據都發過去，沒多久運營商回電說安排人帶路由器檢查確定問題。檢查的小哥沒多久也回電了解情況，先問是否重設了DNS為114，（梅林早已設置過），無解后約了個時間說來檢查。約定的檢查日期來了，我不停的重試測試，還是會被劫持，早上10:30左右，路由器記錄到網絡重連，之后再測試，再也沒出現過劫持，然而檢查人員也并未登門檢查，看來是悄悄把接入點給改了。至此，一場沒有結局的投訴就這樣不明不白的解決了。

反思

整個過程中，面對網絡運營商，用戶人微言輕，舉證困難，運營商可以隨時修改設置關閉劫持。通管局指定運營商自查，并不是指定第三方來審查。運營商“我查我自己”，究竟是內部個別員工作祟還是自身作祟，也不得而知。網絡安全服務提供商極驗，對自己提供的服務未采用https協議傳輸，在這兩年風風火火的全民https時代，顯得尤為落后，更何況自身提供的就是反欺詐等服務，到頭來反而自身服務被劫持，作為受害者兼背鍋俠，也是冤枉。

最后的最后，站長們還沒上https的趕快上吧。