ADVANCED TECHNIQUE BRIEF

Cache keys define exploitable equivalence classes

Prove an origin input is absent from the cache key and produces a response reusable by another request.

Also known as: unkeyed input · cache key poisoning

cache-poisoningcache-keyunkeyed-inputcdn

A cache key asserts that all requests mapping to that key can safely receive the same response. If the origin distinguishes those requests in a security-relevant way, the cache’s equivalence relation is too broad.

Research anchor and scope

James Kettle’s cache-poisoning research investigates unkeyed inputs, response influence, and cache storage as separate conditions. It also stresses cache busters because an existing entry can conceal origin behavior. Product-specific cases are historical findings, not a current vendor vulnerability matrix. This brief focuses on the general equivalence failure and a controlled diagnostic method.

Express the missing dependency

Let K(request) be the cache key and R(request) be the origin response. The interesting situation is two requests A and B with K(A)=K(B) but R(A) differing in a way that is unsafe to reuse for B. Merely finding a reflected header proves origin influence, not cache poisoning.

For a toy application, the origin chooses a harmless greeting from X-Demo-Language, but the cache keys only on path and query. Warm a dedicated test key using one language, remove the header, and request that same key. Receiving the earlier greeting demonstrates the equivalence failure without introducing executable content.

Separate three experiments

First, bypass or miss the cache and compare origin responses with and without the suspected input. Second, determine whether the input changes the key. Third, demonstrate storage and reuse with a clean request. Keep the cache buster fixed during the storage test and change it between unrelated experiments. Randomizing it on every request makes reuse impossible to observe.

Measure the response body and relevant headers together. An increasing age or a cache-hit marker is useful supporting evidence, but multiple cache layers can attach misleading indicators. Compare a fresh key, a warmed key, and a deliberately expired key if the environment permits. Test cacheability of the exact status, content type, authentication state, and response directive involved.

Impact requires a consumer

A stored arbitrary header value becomes dangerous only through its effect on a later response consumer. A generated resource URL, redirect destination, document base, or configuration field may offer a useful chain; plain text reflection may not. Browser constraints on cookies, content types, script loading, and redirects should be tested rather than inferred from a proxy response.

State which visitors share the key, cache region, and lifetime. A private per-user cache changes impact substantially. A single poisoned entry does not establish global persistence. Conversely, an apparently harmless wrong-language entry may reveal the same missing key dependency that affects a more sensitive origin branch. Repair the equivalence relation by keying meaningful variation or preventing storage of the variable response.

Sources & further reading

  1. Practical Web Cache Poisoning ↗James Kettle · portswigger

Content license: CC BY 4.0. Source-derived sections retain their cited licenses and redistribution notices. How this reference is compiled →