
Practical Web Cache Poisoning - 4kevinking
https://portswigger.net/blog/practical-web-cache-poisoning
======
tptacek
I think you can think of this as a generalized technique for turning reflected
cross-site scripting into stored cross-site scripting.

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.

------
andrewstellman
"Practical" is right – a seemingly "theoretical" exploit turns out to have
serious practical implications. This is a really well-written article with
lots of examples.

Excellent work!

------
wtmt
This is a well written article with many details. What caught my eye was the
following.

> “To exploit this, we need to go to hubspot.com, register ourselves as a
> HubSpot client, place a payload on our HubSpot page, and then finally trick
> HubSpot into serving this response on goodhire.com

> ...

> Cloudflare happily cached this response and served it to subsequent
> visitors. Inflection passed this report on to _HubSpot, who resolved the
> issue by permanently banning my IP address._ After some encouragement they
> also patched the vulnerability.”

This made me chuckle as well as get frustrated with how most teams and
organizations react to security issue reports by first going into denial. They
then try shutting up or preventing the person/entity reporting the incident
from accessing the system, while continuing to proceed with “business as
usual” and claiming that their systems are perfect. Good that HubSpot did
patch the vulnerability soon after in this case.

If someone were to ask me for comments, I’d say people and organizations need
to grow up, own up and work better. Such reactions show a lot of immaturity
while keeping their users vulnerable.

P.S.: In the Indian context, this kind of a response reminds me of UIDAI (the
organization that manages the biometric based resident ID system), which is
permanently in denial mode when vulnerabilities related to security and
privacy in its ecosystem and all the entities that link to it are pointed out.

------
jusob
In 2017 or 2016, there was a Blackhat talks that explained how to trick the
web cache on main popular website (including Paypal) into caching any web
page. The trick is that many web cache just do a check on the extension (.jpg,
.png) to check whether to cache a page or not. If you added ?foo=.png to any
page, it would be cached. The host showed how he could trick any web visitor
to access their Paypal account home page (if logged in) and cache any page
that he would later visit.

~~~
albinowax_
Yes, this is called Web Cache Deception and is referenced in the article
above:

 _Please note that web caches also enable a different type of attack called
Web Cache Deception which should not be confused with cache poisoning._

------
sciurus
The bug for the problem James found with the configuration of Normandy
([https://github.com/mozilla/normandy](https://github.com/mozilla/normandy)),
Mozilla's system for distributing Shield studies , is now public at
[https://bugzilla.mozilla.org/show_bug.cgi?id=1433134](https://bugzilla.mozilla.org/show_bug.cgi?id=1433134)

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

------
jiveturkey
amazing article. i believe it advances the state of the art. extremely well
presented.

------
data_spy
The website I work at has an advertising partner cache bids and creatives,
could these in theory be hijacked?

~~~
joeyrideout
I watched the author's talk at Black Hat yesterday and to my understanding,
yes. It's a matter of tricking the cache into storing a request with malicious
unkeyed input.

i.e. The cache looks for:

GET /advertisement/1

And caches the request body and other headers as a value with that line as the
key. If you can manipulate the same key to have a different value, say by
tweaking a cache-specific header, then the body of that GET response (an ad)
changes for everyone hitting the same cache. Certainly worth testing with the
tools that have been released ;)

EDIT: The tool in question, a plugin for Burp Community + Pro:
[https://github.com/PortSwigger/param-
miner](https://github.com/PortSwigger/param-miner)

------
freen
This is top notch.

