web-cache-deception

Web Cache Deception Detection

Overview

Web cache deception makes a shared cache store a response that contains one user's private, personalised content under a cache key that a different, unauthenticated party can request. It lives in the gap between two URL parsers on the request path: the edge cache decides what to store from superficial URL features (a file extension, a directory prefix, a well-known file name), while the origin resolves the same URL to a dynamic, authenticated route. The attacker is an unauthenticated remote party who crafts a URL satisfying the cache's "this is a static asset" rule while the origin still renders the victim's page, lures the victim into loading it once, then fetches the same URL themselves and reads whatever the cache stored — session-bearing markup, PII, tokens, sometimes credentials. This skill finds such exposure by locating every authenticated response that could become cacheable together with every rule and routing behaviour that could make it so, checking each candidate in parallel, and merging the results into <output_dir>/web-cache-deception-results.md.

What it is NOT

• Web cache poisoning (/websec:web-cache-poisoning): poisoning is an integrity attack — the cache stores an attacker-influenced response and serves it to victims. Deception is a confidentiality attack — the cache stores a victim's own response and the attacker fetches it. Test: ask who owns the bytes in the cache entry. If they are the attacker's payload being delivered to others, it is poisoning; if they are a victim's private data being read by the attacker, it is deception.
• Path traversal (/websec:path-traversal): there the ..%2f sequence reaches a filesystem read and returns file contents. Here it only shifts which URL string the cache and the origin each believe they are handling; no file is opened out of bounds. Test: does the encoded segment change a file path, or only a route and a cache key?
• Access control (/websec:access-control): the origin's authorization may be entirely correct — the victim was authenticated and entitled to that page. The flaw is that the response became shareable. Test: remove the cache from the picture; if the private data is still reachable by the wrong principal, it is an authorization bug.
• Information disclosure (/websec:information-disclosure): there the application volunteers data to whoever asks (debug pages, backups, verbose errors). Here the data is correctly scoped at the origin and only leaks through a stored copy.
• Host header handling (/websec:host-header): a host-derived cache key problem belongs there; deception turns on path and extension parsing, not on the host.
• Request smuggling (/websec:request-smuggling): both turn on two hops disagreeing, so name what they disagree about. Test: do the hops disagree about the URL and the cache key derived from it (here), or about where one request ends and the next begins on a reused connection (there)?
• Not a finding: a cached response that is identical for every user (genuinely static, or personalised only by content the requester already knows); a route that returns 404 or 400 for the crafted suffix instead of the base page; an authenticated response that carries Cache-Control: no-store on every branch; caching confined to a hostname or path prefix that serves no authenticated content; an Age header on a response whose body contains no requester-specific data.