Lab: Exploiting exact-match cache rules for web cache deception

Identify a target endpoint

1. In Burp's browser, log in to the application using the credentials wiener:peter, then change your email address.

2. In Proxy > HTTP history, notice that the email change submission form in the /my-account response contains a CSRF token as a hidden parameter.

Investigate path delimiter discrepancies

1. Right-click the GET /my-account request and select Send to Repeater.

2. In Repeater, change the URL path to /my-account/abc, then send the request. Notice the 404 Not Found response. This indicates that the origin server doesn't abstract the path to /my-account.

3. Change the path to /my-accountabc, then send the request. Notice that this returns a 404 Not Found response with no evidence of caching.

4. Right-click the request and select Send to Intruder.

5. In Intruder, craft an attack to identify whether the origin server uses any path delimiters. Use the payload: /my-account§§abc. Notice that ; and ? are both used as delimiters.

6. Go to the Repeater tab that contains the /my-account/abc request. Update the path to /my-account?abc.js, then send the request. Notice that the response doesn't contain evidence of caching.

7. Repeat this test using the ; character instead of ?. Notice that the response doesn't show evidence of caching.

Investigate normalization discrepancies

1. Add an arbitrary directory followed by an encoded dot-segment to the start of the original path. For example, /aaa/..%2fmy-account.

2. Send the request. Notice that this receives a 404 response. This indicates that the origin server doesn't decode or resolve the dot-segment to normalize the path to /my-account.

3. In Proxy > HTTP history, notice that static resources share the URL path directory prefix /resources. Notice that none of these show evidence of being cached. This indicates that there isn't a static directory cache rule.

4. In Repeater, change the URL path of the /my-account request to /robots.txt.

5. Send the request. Notice that the response contains the X-Cache: miss header. Resend and notice that this updates to X-Cache: hit. This indicates that the cache has a rule to store responses based on the /robots.txt file name.

6. Add an encoded dot-segment and arbitrary directory before /robots.txt. For example, /aaa/..%2frobots.txt.

7. Send the request. Notice that the 200 response is cached. This shows that the cache normalizes the path to /robots.txt.

Exploit the vulnerability to find the administrator's CSRF token

1. Use the ? delimiter to attempt to construct an exploit as follows: /my-account?%2f%2e%2e%2frobots.txt. Send the request. Notice that this receives a 200 response, but doesn't contain evidence of caching.

2. Repeat this test using the ; delimiter instead of ?. Notice that this receives a 200 response with your API key and the X-Cache: miss header. Resend and notice that this updates to X-Cache: hit. This indicates that the cache normalized the path to /robots.txt and cached the response. You can use this payload for an exploit.

3. In Burp's browser, click Go to exploit server.

4. In the Body section, craft an exploit that will navigate the victim user to the malicious URL you crafted. Make sure to add an arbitrary parameter as a cache buster:

   <script>document.location="https://YOUR-LAB-ID.web-security-academy.net/my-account;%2f%2e%2e%2frobots.txt?wcd"</script>

5. Click Deliver exploit to victim.

6. Go to the URL that you delivered to the victim in your exploit:

   https://YOUR-LAB-ID.web-security-academy.net/my-account;%2f%2e%2e%2frobots.txt?wcd

7. Notice that in Burp's browser this redirects to the account login page. This may be because the browser redirects requests with invalid session data. Attempt the exploit in Burp instead.

8. Go to the Repeater tab that contains the /my-account request. Change the path to reflect the URL that you delivered to the victim in your exploit. For example, /my-account;%2f%2e%2e%2frobots.txt?wcd.

9. Send the request. Make sure you do this within 30 seconds of delivering the exploit to the victim. Otherwise, send the exploit again with a different cache buster.

10. Notice that the response includes the CSRF token for the administrator user. Copy this.

Craft an exploit

1. In Proxy > HTTP history, right-click the POST /my-account/change-email request and select Send to Repeater.

2. In Repeater, replace the CSRF token with the administrator's token.

3. Change the email address in your exploit so that it doesn't match your own.

4. Right-click the request and select Engagement tools > Generate CSRF PoC.

5. Click Copy HTML.

6. Paste the HTML into the Body section of the exploit server.

7. Click Deliver exploit to victim to solve the lab.