This lab supports both the X-Forwarded-Host and X-Forwarded-Scheme headers.
                
Lab: Web cache poisoning with multiple headers
            This lab contains a web cache poisoning vulnerability that is only exploitable when you use multiple headers to craft a malicious request. A user visits the home page roughly once a minute. To solve this lab, poison the cache with a response that executes alert(document.cookie) in the visitor's browser.
        
 Hint
 Solution
- With Burp running, load the website's home page.
- 
                        Go to "Proxy" > "HTTP history" and study the requests and responses that you generated. Find the GETrequest for the JavaScript file/resources/js/tracking.jsand send it to Burp Repeater.
- 
                        Add a cache-buster query parameter and the X-Forwarded-Hostheader with an arbitrary hostname, such asexample.com. Notice that this doesn't seem to have any effect on the response.
- 
                        Remove the X-Forwarded-Hostheader and add theX-Forwarded-Schemeheader instead. Notice that if you include any value other thanHTTPS, you receive a 302 response. TheLocationheader shows that you are being redirected to the same URL that you requested, but usinghttps://.
- 
                        Add the X-Forwarded-Host: example.comheader back to the request, but keepX-Forwarded-Scheme: nothttpsas well. Send this request and notice that theLocationheader of the 302 redirect now points tohttps://example.com/.
- 
                        Go to the exploit server and change the file name to match the path used by the vulnerable response: /resources/js/tracking.js
- 
                        In the body, enter the payload alert(document.cookie)and store the exploit.
- 
                        Go back to the request in Burp Repeater and set the X-Forwarded-Hostheader as follows, remembering to enter your own exploit server ID:X-Forwarded-Host: YOUR-EXPLOIT-SERVER-ID.exploit-server.net
- 
                        Make sure the X-Forwarded-Schemeheader is set to anything other thanHTTPS.
- 
                        Send the request until you see your exploit server URL reflected in the response and X-Cache: hitin the headers.
- 
						To check that the response was cached correctly, right-click on the request in Burp, select "Copy URL", and load this URL in Burp's browser. If the cache was successfully poisoned, you will see the script containing your payload, alert(document.cookie). Note that thealert()won't actually execute here.
- Go back to Burp Repeater, remove the cache buster, and resend the request until you poison the cache again.
- 
						To simulate the victim, reload the home page in the browser and make sure that the alert()fires.
- Keep replaying the request to keep the cache poisoned until the victim visits the site and the lab is solved.
 
                                 
                                