Lab: Combining web cache poisoning vulnerabilities
This lab is susceptible to web cache poisoning, but only if you construct a complex exploit chain.
A user visits the home page roughly once a minute and their language is set to English. To solve this lab, poison the cache with a response that executes
alert(document.cookie) in the visitor's browser.
This lab requires you to poison the cache with multiple malicious responses simultaneously and coordinate this with the victim's browsing behavior.
- With Burp running, load the website's home page.
Use Param Miner to identify that the
X-Original-URLheaders are supported.
In Burp Repeater, experiment with the
X-Forwarded-Hostheader and observe that it can be used to import an arbitrary JSON file instead of the
translations.jsonfile, which contains translations of UI texts.
Notice that the website is vulnerable to DOM-XSS due to the way the
initTranslations()function handles data from the JSON file for all languages except English.
Go to the exploit server and edit the file name to match the path used by the vulnerable website:
In the head, add the header
Access-Control-Allow-Origin: *to enable CORS.
In the body, add malicious JSON that matches the structure used by the real translation file. Replace the value of one of the translations with a suitable XSS payload, for example:
"Return to list": "Volver a la lista",
"View details": "</a><img src=1 onerror='alert(document.cookie)' />",
Note: For the rest of this solution we will use Spanish to demonstrate the attack. If you injected your payload into the translation for another language, you will also need to adapt the examples accordingly.
- Store the exploit.
In Burp, find a
/?localized=1that includes the
langcookie for Spanish:
Send the request to Burp Repeater. Add a cache buster and the following header, remembering to enter your own exploit server ID:
- Send the response and confirm that your exploit server is reflected in the response.
To simulate the victim, load the URL in your browser and confirm that the
- You have successfully poisoned the cache for the Spanish page, but the target user's language is set to English. As it's not possible to exploit users with their language set to English, you need to find a way to forcibly change their language.
In Burp, go to "Proxy" > "HTTP history" and study the requests and responses that you generated. Notice that when you change the language on the page to anything other than English, this triggers a redirect, for example, to
/setlang/es. The user's selected language is set server side using the
lang=escookie, and the home page is reloaded with the parameter
GETrequest for the home page to Burp Repeater and add a cache buster.
Observe that the
X-Original-URLcan be used to change the path of the request, so you can explicitly set
/setlang/es. However, you will find that this response cannot be cached because it contains the
Observe that the home page sometimes uses backslashes as a folder separator. Notice that the server normalizes these to forward slashes using a redirect. Therefore,
X-Original-URL: /setlang\estriggers a 302 response that redirects to
/setlang/es. Observe that this 302 response is cacheable and, therefore, can be used to force other users to the Spanish version of the home page.
You now need to combine these two exploits. First, poison the
GET /?localized=1page using the
X-Forwarded-Hostheader to import your malicious JSON file from the exploit server.
Now, while the cache is still poisoned, also poison the
GET /page using
X-Original-URL: /setlang\esto force all users to the Spanish page.
To simulate the victim, load the English page in your browser and make sure that you are redirected and that the
- Replay both requests in sequence to keep the cache poisoned on both pages until the victim visits the site and the lab is solved.