web-cache-poisoning

Web Cache Poisoning Detection

Overview

Web cache poisoning makes a shared cache store an attacker-influenced response and then serve it to everyone who requests the same cache key. The attacker finds an input that reaches the application and changes the response but that the cache leaves out of its key — a forwarded-host header, a cookie, a stripped query parameter, a port, a request body the cache never reads — uses it to elicit a harmful response, and lets the cache do the distribution. It sits at the edge of the request lifecycle, between the client and the origin; the attacker is an unauthenticated remote party, and a single request can affect every subsequent visitor to the affected URL for as long as the entry lives. Poisoning is a delivery mechanism: the damage is whatever the poisoned response does — script execution, a hostile script import, a redirect, a broken page — multiplied by that URL's traffic. This skill finds it by locating every request-derived value that reaches a response together with every cache-key decision that could leave that value unkeyed, checking each candidate in parallel, and merging the results into <output_dir>/web-cache-poisoning-results.md.

What it is NOT

• Web cache deception (/websec:web-cache-deception): deception is a confidentiality attack — the cache stores a victim's own private response and the attacker fetches it back. Poisoning is an integrity attack — the cache stores an attacker-influenced response and serves it to victims. 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.
• Reflected cross-site scripting (/websec:xss): a reflected payload that reaches only the person who sent it is that class. It becomes poisoning only when the response is stored and served to others. Test: does a clean request from a different client receive the payload? If nothing is cached, report the underlying reflection to the sibling skill.
• DOM-based issues (/websec:dom-based): a client-side sink consuming imported data is that class; poisoning is what makes the imported data attacker-controlled and persistent. Classify the sink there and the storage here.
• Host header handling (/websec:host-header): the host and its override headers are one input; poisoning is one way to weaponise them. If the harm is a poisoned reset link or host-based routing to an internal service, it belongs to the sibling skill.
• Request smuggling (/websec:request-smuggling): smuggling desynchronises request boundaries between servers; it is a different way to get a response into a cache. If the mechanism is a length disagreement across hops rather than an unkeyed input, it belongs there.
• Open redirect handling (/websec:open-redirect): a redirect whose destination the request influences is that skill's finding on its own; poisoning is only the amplifier. Test: does the destination bend for the person who sent the request (sibling skill), or does a stored copy send other visitors to it (here)?
• Not a finding: an input that is reflected but is part of the cache key, so only the sender ever sees it; a response marked no-store on every branch with no rule overriding it; an in-process memo or per-user cache not shared between clients; a Vary header that keys the very input in question; reflection into a context where it is correctly encoded and cannot change behaviour.