Bypassing Web Cache Deception and Poisoning via Path Normalization Discrepancies

TLDR: Modern web caches and origin servers often disagree on how to normalize URL paths, creating a massive attack surface for cache deception and poisoning. By injecting specific path delimiters like semicolons or encoded null bytes, researchers can force caches to store sensitive dynamic responses or serve malicious payloads to unsuspecting users. Pentesters should audit their target's cache configuration for these normalization mismatches to identify high-impact, full-site takeover vectors.

Web caches are the silent workhorses of the internet, but they are also a goldmine for anyone looking to bypass security controls. When a front-end cache proxy and a back-end origin server interpret a URL path differently, the resulting discrepancy is not just a minor bug. It is a critical vulnerability that can lead to full-site takeovers, sensitive data exfiltration, and widespread cache poisoning.

The core of the problem lies in how different technologies handle path normalization. A cache proxy might see a request for /MyAccount/a.js and, because it ends in a static extension, decide to cache the response. Meanwhile, the back-end server might ignore the .js suffix or treat it as a parameter, returning the user's private account details. If the cache stores that response, any subsequent user requesting that same URL—or even a slightly modified version—could receive the victim's sensitive data.

The Mechanics of Path Confusion

Exploiting these discrepancies requires a deep understanding of how your target's stack parses URLs. The research presented at Black Hat 2024 demonstrates that we can manipulate the cache key by injecting specific characters that act as delimiters. These characters, such as the semicolon in Spring Framework or the dot in Ruby on Rails, effectively trick the cache into seeing a static file while the origin server processes the request as a dynamic, sensitive endpoint.

Consider a scenario where an application uses a path like /MyAccount/param1/param2. If the back-end only cares about the prefix, an attacker can send a request for /MyAccount/a.js. The cache sees the .js extension and caches the response. The back-end, however, sees the request as a valid path to the user's account handler. The result is a classic Web Cache Deception attack where the attacker can steal PII or session tokens simply by sending a malicious link to a victim.

Beyond Simple Deception

While deception is powerful, cache poisoning offers a more direct path to compromise. By manipulating the cache key, an attacker can force the cache to store a malicious response—such as a reflected XSS payload—and serve it to every user who hits that cache node.

The most effective way to identify these vulnerabilities is to test how your target handles various path delimiters. You can use a tool like CacheKiller, a Burp Suite extension designed to help researchers detect these path confusion issues. During an engagement, focus on how the cache and the origin server handle characters like #, ;, and encoded null bytes. If you see an X-Cache: Hit header after sending a request with a modified path, you have likely found a discrepancy that warrants further investigation.

Real-World Impact and Defensive Realities

These attacks are not theoretical. They affect major CDNs and frameworks, including Nginx, Apache, and various cloud-native platforms. The impact is often severe because it bypasses traditional client-side protections like Content Security Policy (CSP). If you can poison a cached JavaScript file, you control the execution context of the entire application for every user.

Defending against these attacks is notoriously difficult because the issue is rooted in the fundamental design of how web servers and caches communicate. The most effective mitigation is to ensure that the cache proxy and the origin server share an identical understanding of what constitutes a "static" resource. If your cache is configured to ignore certain parameters or path segments, ensure that the origin server is not using those same segments for sensitive logic.

For those of you in the field, stop treating the cache as a black box. Start mapping the normalization rules of your target's infrastructure early in your reconnaissance phase. If you find that the cache is stripping characters that the back-end is using for routing, you have found your entry point. These vulnerabilities are rarely patched because they are often considered "intended behavior" by vendors, which means they will remain a reliable vector for years to come. Focus your efforts on identifying these normalization gaps, and you will find that the most complex-looking applications often have the simplest, most devastating flaws hidden in their cache configuration.