Practical Web Cache Poisoning

The concept is straightforward. You look for refxss in "unkeyed" inputs: those are inputs that alter the output of a cacheable page but aren't themselves part of the cache key. That "unkeyed" property is why his examples are all in things like the X-Forwarded-For header. Caches key on URL parameters (because they key on URLs), but tend not to use that header as a key, so two requests varying only in X-Forwarded-For are, to a cache, the same request. If you can trigger refxss in the unkeyed input, that refxss will be cached and fed to everyone else regardless of whether they use the same unkeyed input. Presto: stored XSS.

While that's super cool, if you're not already familiar with modern web application testing, I think the more interesting part of this post is the tour you get of the methodology Kettle uses to find vulnerabilities in the first place. The XSS examples he's providing aren't "novel"; the novelty is in tricking caches into storing them. But he uses the post as an opportunity to show off some advanced Burp features, which is useful even if you're not going to go test for cache poisoning.

We were bitten because django's ALLOWED_HOSTS was set to accept anything and django's USE_X_FORWARDED_HOST setting was true.