Web cache poisoning: exploiting an unkeyed input

Web cache poisoning turns a performance feature into a delivery mechanism: an attacker gets one malicious response stored in a shared cache, and the cache then serves it to everyone behind it. Here is how it works, what it costs, and how to close it.

The attack has two stages. First the attacker gets the server to produce a harmful response, usually by feeding it a header the application reflects but the cache does not key on. Then they get that response stored, so every later request for the same key is answered with it. XSS, JavaScript injection and open redirection all become far more damaging once delivered this way.

The attack only makes sense once you know how a cache decides two requests are the same. A cache stores a response for a fixed period and serves it to any later request it considers equivalent, skipping the back end entirely. It decides equivalence with a “cache key”, normally the request line plus the Host header. Everything outside that key is ignored for matching but can still reach the application, and that gap is the whole vulnerability.

The severity of a web cache poisoning attack hinges on the nature of the payload and the traffic volume to the affected page. For instance, a poisoned cache on a major website’s homepage could impact thousands of users.

To execute a web cache poisoning attack, attackers follow these steps:

• Identify and Evaluate Unkeyed Inputs: Attackers look for server-supported unkeyed inputs, like headers, that can be manipulated to inject a payload.
• Elicit a Harmful Response: When the server accepts, the aim is to modify inputs to prompt a server response containing the malicious payload.
• Cache the Response: Requests are then answered however, success depends on caching the harmful response for widespread distribution.

The strongest defence against web cache poisoning is a caching policy that caches static content and nothing else. The measures below tighten that further:

• Strict Cache Key Management: Protect cache keys from mismatches and potential poisoning by ensuring they are comprehensively representing request identities.
• Reject Unnecessary Requests: Avoid accepting large GET requests, which might be allowed by some technologies by default.
• Update Regularly: Patch client-side vulnerabilities regularly, even if they appear unexploitable, to prevent exploitation through cache behavior quirks.
• Remove Malicious Inputs: Carefully purge unkeyed inputs to prevent malicious data from triggering harmful responses from the server.
• Audit third-party technology: every integration you add brings its own header handling. Disable headers you do not use, and check what each vendor reflects before trusting it behind a shared cache.
• Educate and Train: Equip your development and security teams with knowledge about web cache poisoning threats and defensive coding practices.

Web cache poisoning is difficult to spot and expensive when it lands, but it is not difficult to defend against once the cache key is understood. Audit what your cache keys on, cache static content only, and treat every unkeyed header as an input an attacker controls.