【HTTP劫持和DNS劫持】騰訊的實際業務分析

    簡單介紹一下HTTP劫持和DNS劫持的概念,也就是運營商經過某些方式篡改了用戶正常訪問的網頁,插入廣告或者其餘一些雜七雜八的東西。
 
    首先對運營商的劫持行爲作一些分析,他們的目的無非就是賺錢,而賺錢的方式有兩種:
    一、對正常網站加入額外的廣告,這包括網頁內浮層或彈出廣告窗口;
    二、針對一些廣告聯盟或帶推廣連接的網站,加入推廣尾巴。例如普通訪問百度首頁,被前置跳轉爲 http://www.baidu.com/?tn=90509114_hao_pg 
 
 
     在具體的作法上,通常分爲DNS劫持和HTTP劫持。
     DNS劫持:
    通常而言,用戶上網的DNS服務器都是運營商分配的,因此,在這個節點上,運營商能夠隨心所欲。
    例如,訪問http://jiankang.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了)html

 
    二、針對被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展現原來正常網頁。
 
   各類醜惡的嘴臉都被記錄在案:
  
  
  
相關文章
相關標籤/搜索