Web Traffic Hijacking: Risks, Techniques, and Defenses

The previous article introduced common traffic hijacking methods. However, regardless of how the traffic is obtained, it only becomes useful when it is exploited.

Different hijacking methods capture different types of traffic. DNS hijacking can only intercept traffic initiated via domain names, while direct IP communication is unaffected; CDN intrusion poses risks only when browsing or downloading web pages; a compromised gateway can capture all user traffic.

In this article, we explain the following questions based on technical principles:

Why do attackers like to hijack web pages?

Is it safe to browse without logging in?

Is auto‑filling forms risky?

Does leaving the hijacked environment still affect me?

Can HTTPS prevent hijacking?

Can traffic hijacking control my computer?

Why do attackers like to hijack web pages?

In theory, hijacking a user's traffic gives access to the network communication of the corresponding program. In practice, the captured data rarely represents the actual content because many important network programs use proprietary binary protocols and encryption. Reconstructing chat messages or payment passwords from traffic is almost impossible. Even if an attacker manages to reverse‑engineer a protocol, a future program update can render the effort useless, making a universal client‑side hijacking solution infeasible.

However, not all programs are client‑side. The rise of WebApps—fast‑growing, cross‑platform applications with cloud support—has created unprecedented opportunities for traffic hijacking.

A WebApp is essentially a regular web page. Although web technologies have advanced, the underlying protocol remains HTTP, a 20‑year‑old plain‑text protocol.

In HTTP, everything is transmitted in clear text, allowing traffic to be freely intercepted. Traditional native programs run locally and only generate communication traffic, whereas WebApps transmit both communication data and the program’s UI and code, making hijacking trivial.

The previous article mentioned that in outdoor areas without 3G signal, captured traffic cannot be forwarded to the Internet. Using web pages solves this problem: an attacker can set up a site on their own device to retain user traffic, and devices that automatically pop up pages when connected to Wi‑Fi become even easier to compromise.

Therefore, hijacking web traffic has become a favorite technique for many hackers, as it enables XSS‑style attacks on any web page.

Below, we begin our offensive‑defensive journey.

Is it safe to browse without logging in?

Whenever experts issue warnings, they often say: avoid logging into accounts in public places. Consequently, many people assume that merely viewing a web page without logging in is safe.

If you are using a public computer, that assumption may hold; otherwise, your personal accounts could be at risk.

On personal devices, users often keep login sessions active, believing that only they can use the browser. In a hijacked network, however, anything can happen. Even a seemingly harmless page may contain a silent spy script that silently accesses logged‑in sites and takes control of your accounts.

It may sound far‑fetched, but HTTP is stateless and relies on cookies to maintain login state. If an attacker obtains a cookie, they effectively gain the user’s authentication token.

Unlike traditional XSS attacks, traffic hijacking can capture any communication data, including HttpOnly‑protected cookies. The malicious script merely needs to request a target site; the attacker intercepts the transmitted cookie. By targeting many sites simultaneously, a large portion of users can be compromised.

This request does not need to load a full page; loading the URL as an image is enough to exfiltrate the target site’s cookie.

With the stolen cookie, the attacker can recreate the logged‑in session in their own browser. Even though you did not actively log in, the existing sessions can betray you.

Defensive measure: For important sites, avoid keeping login sessions active to prevent cookie leakage. Binding cookies to IP ranges can reduce the risk, but relying solely on HttpOnly is insufficient.

Is auto‑filling forms risky?

Even if an attacker obtains cookies and can act as the user, passwords remain unknown, so control can be lost at any time.

Many users let browsers automatically save passwords. Can this be abused to extract saved passwords?

The mechanism is simple: the browser matches the page URL and form field names with stored records and auto‑fills them.

If traffic is under the attacker’s control and the page content is stripped down to just the form, what happens?

The saved password is still auto‑filled and can be accessed by malicious scripts!

By injecting numerous hidden iframe pages into the victim’s browsing context, an attacker can attempt to harvest saved credentials from various sites (modern Chrome no longer auto‑fills hidden iframes, but the exact behavior depends on the browser).

Even if hidden iframes stop auto‑filling, the main page still retains the feature. If a user’s page has been idle for a while, the attacker can silently redirect it to a pure form page, repeatedly attempting credential extraction until the user returns to the original tab.

Because the leaked data includes clear‑text usernames and passwords, even a small amount can be leveraged via social engineering to obtain further personal information, leading to more severe breaches.

Defensive measure: For critical accounts, avoid using browser‑saved passwords or auto‑fill features.

Browser auto‑fill should require explicit user interaction and limit the number of fills within a given time frame.

Does leaving the hijacked environment still affect me?

You might think that once you leave an insecure network, the danger disappears.

In public places with free Wi‑Fi, users often browse news for a few minutes. Even such short exposure can be dangerous because an intrusion script can act instantly; the duration does not significantly affect the attack’s success.

If the attacker’s goal is only immediate gain, a brief intrusion may seem limited. However, if the attacker aims for long‑term control, the script can persist and act later, effectively transcending time and space.

Traditional XSS thinking would deem this impossible, but with traffic hijacking, anything is possible because the attacker controls arbitrary traffic.

HTTP Cache Poisoning

Any place that caches resources is a potential attack surface. HTTP, being a simple plain‑text protocol, lacks built‑in signatures to verify content authenticity. Even if a page is tampered with, the browser cannot detect it, and injected scripts can be cached along with the page.

Attackers can inject “poisoned” versions of executable resources during pre‑loading, causing them to be cached.

To maximize impact, attackers first identify stable resources on popular sites—files with long expiration times and infrequent updates.

When a user opens any HTTP page, the injected XSS script pre‑loads these resources. Because all traffic is under the attacker’s control, the response can be the malicious script instead of the legitimate resource.

The browser caches each malicious response. By collecting many resource URLs, the attacker can infect as many caches as possible during the user’s online session.

Later, when the user visits a site that references any of these resources, the dormant malicious script awakens.

Unless the user clears the cache, the infected scripts remain attached to the browser cache until a forced refresh or cache purge occurs.

Offline Storage Poisoning

Some sites use short‑lived caches, limiting the effectiveness of the previous technique. HTML5 introduced a new caching mechanism—offline storage (AppCache)—which lacks an expiration time and can be poisoned for any page.

After the injection script triggers, the attacker creates an invisible iframe that loads a malicious page. Through traffic hijacking, the server returns a simple page containing a manifest‑enabled HTML document and a payload script.

The browser, unaware of the deception, caches this page in offline storage.

Later, when the user opens the infected site, the browser retrieves the page from offline storage, automatically executing the embedded script.

Because the page is essentially blank, the attacker can embed the original site in a same‑origin iframe and append a random query string to force fresh content.

Since the iframe shares the same origin, the malicious script retains control.

The impact of offline storage poisoning is somewhat limited. When the user later accesses the page over a secure network, the browser may request the .appcache file; if it does not exist, the offline data can be discarded.

In theory, there is only a single activation opportunity, but because the poisoned data never expires, it can affect any HTTP page.

Defensive measure: In insecure environments, use private/incognito mode (e.g., Ctrl+Shift+N in Chrome) to isolate browsing sessions. Firefox prompts users before storing offline files.

Future standards may deprecate iframe‑based offline storage, but HTTP cache poisoning exploits a protocol‑level flaw that is hard to mitigate. The next article will demonstrate the practical impact.

Can HTTPS prevent hijacking?

From a cryptographic standpoint, SSL‑encrypted data is indeed difficult to decipher or modify.

However, attackers can still control the traffic path. They can route the flow through their own servers, effectively bypassing encryption.

Certificate Substitution

Unlike simple HTTP proxies, HTTPS requires a certificate signed by a trusted authority. Self‑signed certificates are not trusted, and browsers will display warnings.

In the past, many users ignored these warnings and proceeded, inadvertently accepting a forged certificate and allowing traffic hijacking.

Modern browsers now issue strong warnings for untrusted certificates, reducing the likelihood of users accepting them.

If an important account site presents such a warning, the user should never proceed, as the “key” to the account may be compromised.

Therefore, certificate substitution attacks have become less effective, prompting attackers to seek more covert methods.

Filtering HTTPS Redirects

On PCs, users often start from HTTP pages before reaching HTTPS sites. For example, users may navigate to Alipay via an HTTP page on Taobao. If an attacker injects XSS into the Taobao page and blocks the HTTPS redirect, the user remains on HTTP and can be continuously hijacked.

Even though the address bar shows the correct domain, the lack of “https” leads users to trust the page.

Thus, if the entry page is insecure, subsequent secure pages offer little protection.

Some users directly type URLs such as www.alipaly.com . The browser assumes HTTP by default, reaches the HTTP version of the site, which merely redirects to HTTPS. An attacker can intercept this redirect, fetch the HTTPS content themselves, and serve it over HTTP, keeping the user trapped in an insecure channel.

Search Engine Hijacking

Many domestic search engines do not provide HTTPS, so search results are delivered over HTTP, making them vulnerable in insecure networks.

Defensive measure: Always verify that important sites use HTTPS and pay extra attention during login.

Most foreign large‑scale websites provide HTTPS by default, whereas many domestic services still rely on plain HTTP, facilitating traffic hijacking.

Can traffic hijacking control my computer?

In theory, browsers isolate web content from the operating system, so the system itself should remain safe.

However, if the attacker can influence downloaded applications, they can execute code outside the browser.

Most download sites use HTTP, allowing attackers to modify executable files, inject malware, or replace them entirely. Users often trust downloads from official sites and may run the compromised binaries without suspicion.

At that point, the compromise extends beyond the browser to the entire system.

Defensive measure: Prefer official app stores for downloads, verify digital signatures, and consider using virtual machines for untrusted software.

When SPDY (or HTTP/2 over TLS) becomes widespread, traffic hijacking of plain HTTP pages will become far more difficult.

Conclusion

That concludes this part. Many XSS‑like techniques exist; we have only covered those that can be combined with traffic hijacking. Using the hijacking methods described in the previous article together with the techniques in this article, attackers can compromise numerous users. The next article will demonstrate a practical attack.

Important Broadcast

Welcome to Baidu Tech Salon. If you like the article, click the top‑right Send to Friends or Share to Moments . You can follow Baidu Tech Salon by:

WeChat ID: bdtechsalon

Or scan the QR code: