HTTP劫持和DNS劫持

HTTP劫持和DNS劫持

首先對運營商的劫持行爲作一些分析，他們的目的無非就是賺錢，而賺錢的方式有兩種：

    一、對正常網站加入額外的廣告，這包括網頁內浮層或彈出廣告窗口；

    二、針對一些廣告聯盟或帶推廣連接的網站，加入推廣尾巴。例如普通訪問百度首頁，被前置跳轉爲http://www.baidu.com/?tn=90509114_hao_pg 

 ----------------------------

關於全站https必要性http流量劫持、dns劫持等相關技術 - 流風，飄然的風 - 博客園
https://www.cnblogs.com/zdz8207/p/https-framework-zatan.html

網站app被劫持怎麼辦?HTTPDNS阿里雲域名防劫持, DNSPod 移動解析服務 D+ - 流風，飄然的風 - 博客園
http://www.cnblogs.com/zdz8207/p/doman-HTTPDNS-DNSPod.html

-----------------------------

    在具體的作法上，通常分爲DNS劫持和HTTP劫持。

    DNS劫持：

    通常而言，用戶上網的DNS服務器都是運營商分配的，因此，在這個節點上，運營商能夠隨心所欲。

    例如，訪問http://xxx.qq.com/index.html，正常DNS應該返回騰訊的ip，而DNS劫持後，會返回一個運營商的中間服務器ip。訪問該服務器會一致性的返回302，讓用戶瀏覽器跳轉到預處理好的帶廣告的網頁，在該網頁中再經過iframe打開用戶原來訪問的地址。

    HTTP劫持：

    在運營商的路由器節點上，設置協議檢測，一旦發現是HTTP請求，並且是html類型請求，則攔截處理。後續作法每每分爲2種，1種是相似DNS劫持返回302讓用戶瀏覽器跳轉到另外的地址，還有1種是在服務器返回的HTML數據中插入js或dom節點（廣告）。

    在用戶角度，這些劫持的表現分爲：

    一、網址被無辜跳轉，多了推廣尾巴；

    二、頁面出現額外的廣告（iframe模式或者直接同頁面插入了dom節點）。

-----------------------------

    處理辦法：

    一、先對外網作檢測，上報被劫持的狀況。

            對於我這個業務而言，加推廣尾巴沒意義，那麼就剩下植入廣告的問題了。頁面廣告可能經過iframe方式，也能夠經過dom節點方式，須要在首頁檢查這兩種狀況。

window.addEventListener('DOMNodeInserted', checkDivHijack);    
function checkDivHijack(e) {
        var html = e ? (e.srcElement.outerHTML || e.srcElement.wholeText) : $('html').html();
        var reg = /http:\/\/([^\/]+)\//g;
        var urlList = html.match(reg);
        if (!urlList || urlList.length == 0) {
            return;
        }
        reg = /^http:\/\/(.*\.qq\.com|.*\.gtimg\.cn|.*\.qlogo\.cn|.*\.qpic\.cn|.*\.wanggou\.com)\/$/;
        var hijack = false;
        for (var i = 0; i < urlList.length; i++) {
            if (!reg.test(urlList[i])) {
                hijack = true;
                break;
            }
        }
}

 

 （注：過後發現這個url檢查不夠嚴謹，雖然劫持的狀況都能發現，但也把產品原有的一些正常插入作劫持誤報了。例如<a href="http://jiankang.qq.com" data-id="1">，不過這個是小細節，把正則表達式完善一下就ok了)

    二、針對被iframe加載的狀況，須要先找到運營商設置的劫持規律。

            在iframe中的網頁能正常打開，而不是又被攔截加iframe，多是由於請求的url上或cookie上運營商作了標記。咱們能夠利用這個規則，躲過劫持。

    三、針對注入dom節點的狀況，初始化時作檢查，並且後續dom注入也作檢查。能夠檢查dom中是否含有白名單之外的http連接，若是有，就能夠斷定爲http劫持。

    四、在前端之外的處理辦法還有

        a) 終端攔截全部返回包，判斷ip來自黑名單（劫持的中間ip）則丟棄返回包。

                這種作法的緣由是，運營商劫持http請求後，並非徹底丟棄請求包，而是作了複製，一份繼續發給目標服務器，另一份作劫持處理直接返回302。由於這個302會比目標服務器的正常返回早得多，因此用戶瀏覽器會只認第一個302，而丟棄後到的正常返回。

                若是先把第一個302丟棄，等待後續正常返回，則問題解決。

        b) 終端攔截請求包，並拆包發送。

                運營商通常判斷是否劫持，經過判斷是否HTTP請求。 通常只會檢測TCP鏈接創建後的第一個數據包，若是其是一個完整的HTTP協議纔會被標記；若是並不是是一個完整的HTTP協議，因爲沒法獲得足夠多的劫持信息，因此並不會被標記爲HTTP協議。 

                因此，只要把請求包切得足夠細，就能躲過一部分劫持（若是運營商學習「牆」大力氣作多包攔截就沒轍了）。

    五、固然，最終，根本解決辦法是使用HTTPS，不過這個涉及到不少業務的修改，成本較高。若是劫持比例小，也許經過適當的補救作法會更好。

　　來看看檢測到的劫持狀況：

整體1500萬pv的業務，一天居然有100萬的劫持上報，即便排除一半的誤報，也表明說20個用戶中，就接近有1個用戶出現被劫持的狀況。

可見，各類小運營商（尤爲是移動）很黑！

　　各類劫持的手段都有：

　　一、直接返回一個帶廣告的HTML；

　　二、在原html中插入js，再經過js腳本安插廣告；

　　三、iframe展現原來正常網頁。