Labs Covered

This write-up focuses on the following EXPERT-level lab from the PortSwigger Web Security Academy related to Web Cache Deception:

5 Exploiting exact-match cache rules for web cache deception

This lab demonstrates how attackers can abuse exact-match cache rules to trick caches into storing sensitive resources.

---

LAB 5 - Exploiting exact-match cache rules for web cache deception

Lab Description

Overview Exploiting File Name Cache Rules

Certain files such as robots.txt, index.html, and favicon.ico are common files found on web servers. They’re often cached due to their infrequent changes. Cache rules target these files by matching the exact file name string.

To identify whether there is a file name cache rule, send a GET request for a possible file and observe whether the response is cached.

🔬 Lab Focus: The following techniques target vulnerabilities in robots.txt, index.html, and favicon.ico.

---

Detecting Normalization Discrepancies

To test how the origin server normalizes the URL path:

• Use a method similar to detecting static directory cache rules.
• Observe whether it resolves encoded dot-segments (%2e%2e) or extra slashes (/).

To test how the cache normalizes the path:

• Send a request like /aaa%2f%2e%2e%2findex.html.

Interpretation:

• ✅ Response is cached → Cache normalizes path to /index.html.
• ❌ Response is not cached → Cache does not normalize; interprets literal string.

---

Exploiting Normalization Discrepancies

If the cache server resolves dot-segments but the origin does not, you can exploit this mismatch.

For example:

• Use /aaa%2f%2e%2e%2frobots.txt if robots.txt is cacheable and normalizable.
• The cache may store a response for /robots.txt, while the origin returns user-specific data.

---

Exploiting Exact-Match Cache Rules for Web Cache Deception (Expert Lab)

🎯 Goal: Change the administrator’s email address using a CSRF exploit.

---

Solution

1. Identify a Target Endpoint

• Log into the app using Burp’s browser with credentials wiener:peter

  

• Change the email address in your profile.

• In Burp → Proxy > HTTP History, observe /my-account contains a CSRF token.

  

2. Investigate Path Delimiter Discrepancies

• Send GET /my-account/hanzala in Repeater → 404 (origin doesn’t resolve)

  

• Send /my-accounthanzala → also 404

  

Test with Intruder

• Set payload /my-account§§hanzala using common delimiters like ;, ?, %2f

Unchecked Payload encoding

• Check responses for evidence of caching we can test two response which have given us 200 response ; ?

3. Test Delimiters in Path

Try:

• /my-account?hanzala.js
• /my-account;hanzala.js
• Observe: 200 OK but no caching

---

4. Investigate Normalization Discrepancies

• Try /aa/..%2fmy-account → 404
• Shows origin server does not decode dot-segments

Next:

• Visit /robots.txt → Observe X-Cache: miss then X-Cache: hit (response is cached)

  

  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.

  

• Try /aaa/..%2frobots.txt → 200 and X-Cache: hit (cache normalized the path)

  

---

5. Exploit the Vulnerability

🧬 Extract Administrator’s CSRF Token

1. Try /my-account?%2f%2e%2e%2frobots.txt → 200 but no cache

   

   • Repeat this test using the ; delimiter instead of ?.

2. Try /my-account;%2f%2e%2e%2frobots.txt → 200 with user data, X-Cache: miss

3. Resend → Now shows X-Cache: hit

   

🛠️ Deliver Exploit to Victim

1. Go to Go to exploit server
2. Paste payload:

<img src="/my-account;%2f%2e%2e%2frobots.txt?wc" />

1. Click Deliver exploit to victim

2. In Burp, send same request:

   • /my-account;%2f%2e%2e%2frobots.txt?wc

3. Confirm the CSRF token for administrator appears

   

---

6. Craft Final CSRF Exploit

1. Right-click POST /my-account/change-email → Send to Repeater

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

   • Change the email address in your exploit so that it doesn’t match your own.
   • Right-click the request and select Engagement tools > Generate CSRF PoC.

   

3 Click Copy html

1. Paste HTML into exploit server’s Body field

1. Click Deliver exploit to victim again to solve the lab

---