Bypassing Web Cache Deception Protections with Path Normalization Discrepancies

TLDR: Modern web caches often fail to normalize URLs consistently, creating a critical gap between how a proxy and an origin server interpret a request. By exploiting these parsing discrepancies, researchers can bypass existing cache deception protections and force the storage of sensitive, dynamic content. This technique effectively turns static-file-based cache rules into a weapon for full site takeovers and data exfiltration.

Caching is the backbone of modern web performance, but it is also a massive, often misunderstood, attack surface. When a cache proxy sits in front of an origin server, it makes a fundamental assumption: that it can safely determine whether a request is for a static resource based on the URL. This assumption is the root of Web Cache Deception, a technique that has evolved significantly since its inception. The latest research demonstrates that we are no longer just looking for simple path-based misconfigurations. We are now looking at fundamental flaws in how different layers of the stack normalize and interpret the same URL.

The Mechanics of Normalization Discrepancies

At the heart of this research is the realization that cache proxies and origin servers rarely agree on what a URL actually means. A cache proxy might see a request for /MyAccount/a.js and, because it ends in a .js extension, decide it is a static file worth caching. The origin server, however, might ignore the .js part entirely, treating the request as a dynamic call to /MyAccount. If the proxy caches the resulting response, it inadvertently stores the user's private account data in a public location.

The real power comes when you introduce path delimiters and normalization. Different servers treat characters like semicolons, null bytes, or even encoded slashes as boundaries for the path. If you send a request like /MyAccount%00a.js, the proxy might see the null byte as a delimiter, truncate the path, and cache the response based on the .js extension. Meanwhile, the origin server might normalize that same request, ignore the null byte, and serve the dynamic content.

Exploiting the Gap

To weaponize this, you need to find a target that uses a cache proxy with a specific set of rules. Most CDNs, including Cloudflare, Fastly, and Akamai, have default rules that cache files based on extensions. The goal is to craft a payload that satisfies the proxy's static file criteria while ensuring the origin server processes it as a dynamic request.

Consider a scenario where you want to poison a site. You can use a payload that includes a path traversal sequence or a specific delimiter that the proxy ignores but the origin server resolves. By chaining this with an Open Redirect, you can force the cache to store a response that redirects users to an attacker-controlled domain.

If you are testing this on an engagement, start by mapping out how the target handles different delimiters. Use a tool like CacheKiller to automate the detection of these discrepancies. If you see an X-Cache: HIT header for a request that should have been dynamic, you have found your entry point.

Beyond Simple Deception

The most dangerous aspect of this research is the ability to chain these techniques. If you can successfully poison a cache with a malicious script, you are not just stealing data; you are executing code in the context of other users. This is particularly effective when you can target high-traffic pages. By manipulating the cache key, you can ensure your malicious response is served to every user who visits the site, effectively achieving a full site takeover without ever needing to compromise the origin server directly.

Defending against these attacks requires more than just standard security headers. While using private and no-store directives in your Cache-Control header is a baseline requirement, it is often insufficient because many CDNs allow these to be overridden by configuration rules. You must audit your CDN configuration to ensure that cache rules are not overly permissive. Specifically, disable cache-control overrides for sensitive paths and ensure that your origin server and cache proxy are using identical URL normalization logic.

What to Do Next

If you are a pentester, stop treating cache configurations as "out of scope" or "too complex." The next time you are looking at a target, look for the X-Cache header. If you see it, start fuzzing the path with different delimiters and encoding schemes. The goal is to find a request that the proxy thinks is static but the server thinks is dynamic.

For those building applications, the takeaway is clear: never trust the proxy to handle your security logic. If a page contains sensitive user data, it must be marked as non-cacheable at the origin. If you rely on your CDN to filter requests, you are leaving the door open for an attacker to simply rewrite the rules of the game. The industry is moving toward more complex, distributed architectures, and as these systems grow, the gaps between them will only become more lucrative for those who know how to look.