Security Risks of Traditional vs. Fancy Login Boxes: HTTPS, XSS, and Cache Poisoning

Traditional Login Box

In previous articles on the dangers of traffic hijacking, we detailed the high risk of HTTP, leading to the adoption of HTTPS for critical operations to protect traffic in transit.

This is the classic login pattern. Although the main page does not use HTTPS, the login redirects to a secure page, so the process remains relatively safe—at least the login page itself is secure.

Even with this secure-page login model, attackers can still intervene by downgrading HTTPS, forging certificates, or redirecting to phishing sites.

Downgrading HTTPS is the most sophisticated technique, and even security‑aware users occasionally slip.

However, user awareness and knowledge are continuously improving. In today's era of online transactions, security awareness is widespread, and users pay extra attention when logging in, much like being cautious when crossing a street.

Over time, users develop a keen eye and can spot anomalies in the address bar.

Therefore, this traditional login mode still offers a degree of security, at least giving users a chance to verify authenticity.

Fancy Login Box

At some point, developers began emulating traditional application interfaces within web pages. Controls, windows, and interactions increasingly resemble native programs, resulting in increasingly flashy effects.

However, despite the flashiness, the underlying nature remains a web page, which cannot hide inherent web security flaws.

When visual effects extend to critical data interactions such as account login, new risks arise because they alter user habits and completely overturn traditional security awareness.

At first glance, there seems to be no issue. Although the login page does not redirect, data is still transmitted over HTTPS, making interception difficult.

Is Using HTTPS on an HTTP Page Meaningful?

If one thinks these login boxes are harmless, they have not grasped the essence of traffic hijacking—traffic is bidirectional, both inbound and outbound.

Hackers who can capture your outbound traffic usually also have means to control inbound traffic, as detailed in the first part of the traffic hijacking series.

HTTPS does protect communication, but in this scenario it only secures the data being sent; inbound traffic remains unprotected.

Since the login box is embedded as a "virtual window" within the main page, everything shares the same page context. The main page still uses insecure HTTP, allowing injected XSS code to easily control the login box.

One might argue this is merely a design flaw. Embedding an HTTPS login page via an iframe would be protected by the same‑origin policy, preventing XSS control.

While this improvement raises security slightly, it remains limited. Since we can control the main page, XSS can dictate all displayed content. Any login box, iframe, or even security plugin can be removed and replaced with a visually identical textbox. After capturing credentials, a backend reverse proxy can perform the login and the front‑end script can forge a success screen.

Thus, using HTTPS on an HTTP page greatly diminishes its significance.

Combining with Cache Poisoning

The second part of the traffic hijacking series introduced HTTP cache poisoning, where temporary hijacking can lead to long‑term infected caches. This attack requires first identifying a relatively stable script resource on the site to poison.

Traditional Login

In traditional login modes, cache poisoning is hard to exploit:

HTTPS resources cannot be infected.

The HTTPS downgrade approach also exits the hijack environment, preventing access to the attacker’s HTTP login page, causing cache invalidation; or the real HTTP login page may reject the cached version and redirect to a proper HTTPS page.

Thus, only by altering links on the main page to redirect users to a phishing site can one barely exploit it.

Floating Layer Login

Creating a sophisticated floating login box requires substantial UI code, often pulling in common libraries like jQuery. These scripts tend to remain unchanged for long periods, making them ideal targets for cache poisoning.

Thus, floating login boxes provide an excellent vector for cache poisoning.

In a previous article on Wi‑Fi traffic hijacking – JS script cache poisoning, we demonstrated poisoning a long‑cached script under www.163.com and using NetEase’s floating login box to harvest credentials. Even though NetEase transmitted data over HTTPS, it was still vulnerable to traffic‑level attacks.

Despite the high risk, Baidu recently upgraded to a floating login box across all its products.

We selected several popular product lines and performed a cache scan:

Indeed, each product line contained scripts that had not been updated for a long time and were heavily cached.

We then launched a phishing hotspot so that any user connecting would become infected on any visited page.

To make the hotspot more covert, we used a discarded Android phone instead of a router (details in the next article).

To avoid disrupting nearby offices, we did not demonstrate a same‑name hotspot phishing; we simply gave it an arbitrary name.

Then we let the "victim" connect to our hotspot:

Since the victim had a web page open, we quickly received an HTTP request. We injected XSS into any page to perform cache poisoning (steps omitted as they are identical to previous explanations).

Then we rebooted the computer and connected to a normal Wi‑Fi (simulating the user returning to a safe environment).

Opening tiebai.baidu.com, everything appeared normal.

Proceeding to login...

We test whether this floating login box can evade the revived XSS script:

The miracle still occurs!

Since the underlying principles were previously explained, we omit them here. In practice, cache poisoning combined with insecure page login boxes is the ideal method for bulk harvesting plaintext credentials.

Irreversible Memory

If we revert to the traditional login mode now, is it still possible? Clearly, it's too late.

When a site first upgrades from traditional to floating login, users usually pause to admire the new design, ensuring it's not a malicious ad before entering credentials.

After repeated use, users become accustomed to the floating login.

Even if sites later remove floating logins, attackers can recreate a similar floating box via XSS, and users will still input credentials due to prior trust.

Security Upgrade

Since the shift is irreversible, reverting offers little benefit. Floating logins provide good UX, and users who lack security awareness prefer the flashy interface.

To retain experience while enhancing security, the optimal solution is to serve every page over HTTPS, fully hardening the site. This is the future direction for websites.