testing-web-cache-deception

Testing web cache deception: when a fake file extension caches a private page

A shared cache and an origin server can disagree about what a URL is. The origin routes by matching a pattern and often ignores a trailing segment, so a request for an account page with a made-up static suffix still returns the account page, authenticated and personal. The cache, meanwhile, decides what to store by a simpler rule, often the apparent file extension or path prefix, and treats that same URL as a harmless static asset it may cache for everyone. When both are true at once, an attacker lures a logged-in victim to the crafted URL, the origin serves the victim's private response, and the cache stores it under a key the attacker can then request unauthenticated, retrieving the victim's data. This is distinct from cache poisoning: nothing in the response is altered; a private response is simply cached where it should never be. The bug is a cacheability decision that diverges from the origin's notion of the same, authenticated resource. You find it by comparing what the cache stores against what the origin actually served.

When to use

• A shared cache or content delivery layer sits in front of authenticated, per-user dynamic responses.
• The cache decides cacheability by file extension, path prefix, or a static-looking pattern.
• The origin ignores or tolerates extra path segments, suffixes, or delimiters when routing a request.

Scope check

Test cache deception only against systems you own or are authorized to assess, on non-production infrastructure, using two test accounts you control so any cached private response is your own, never a real user's data. A confirmed case exposes an authenticated response to an unauthenticated request, so keep every probe within the authorized scope and prefer an isolated instance. If you can't name the authorization, stop.

The loop

1. Establish whether the origin serves authenticated content for the crafted path and the cache stores it, both at once, first. Confirm two things together: that the origin returns the same private, authenticated response for the static-looking URL as for the real one, and that the shared cache actually stores that response. This is the false-positive killer: if the origin returns a not-found or a login redirect for the crafted path, or the cache does not store the response, there is no deception, and a URL that merely looks static is not a finding. Name both behaviors before claiming impact.