LAB 1 - Exploiting Path Mapping for Web Cache Deception#

Lab Description#

Overview: Exploiting Static Extensions and Path Mapping Discrepancies#

Web Cache Deception attacks exploit the difference in how origin servers and CDNs/caches interpret URL paths:

• Origin servers may ignore extra path segments or file extensions due to RESTful routing.
• Caching layers may treat them literally, especially when they end with static file extensions like .js, .css, .jpg.

If a sensitive dynamic page (like /my-account) is accessed via a URL such as /my-account/wcd.js, the server might still respond with the user’s data — but the cache sees it as a static asset and caches it for future requests.

This section demonstrates:

• How file extensions influence caching
• How to identify path mapping vulnerabilities
• How to store private responses in cache for exploitation

Solution#

1. Configure FoxyProxy to route your browser traffic through Burp Suite.
   Ensure that Intercept is turned off, so requests are recorded in Proxy > HTTP History.

2: Log in to the Application

Log in using the following credentials:

• Username: wiener
• Password: peter

This will authenticate you as the test user and trigger a request to the /my-account endpoint, which will include Wiener’s API key in the response.

3. In Burp, go to Proxy > HTTP History, locate the request to GET /my-account, and send it to Repeater.

4. In the Repeater tab, change the path to /my-account/hanzala and click Send.

• You’ll still see your API key in the response.
• This confirms the server is abstracting the path and returning user-specific data.

5. Modify the path again, this time to include a static file extension:

1
/my-account/hanzala.js

Send the request and check the headers:

• X-Cache: miss → means it’s not yet cached
• Cache-Control: max-age=30 → tells the cache to store it for 30 seconds

6. Send the same request again within 30 seconds.

• Now, X-Cache: hit will appear — confirming that the response is cached.

Exploit Execution#

1. Go to the Exploit Server in your lab instance.

2. Craft an HTML payload that redirects the victim (Carlos) to a new static-looking path that hasn’t been cached by you yet:

1
<script>
2
document.location="https://YOUR-LAB-ID.web-security-academy.net/my-account/hanzalaa.js"
3
</script>

NOTE

Make sure the path (hanzalaa.js) is different than the one you cached previously, so the victim gets a clean cache entry.

3. Click Deliver exploit to victim.

Validate the Attack#

1. In Burp Suite, send a request to:

   1
   /my-account/hanzalaa.js
   

2. This time, the cached response will contain Carlos’s API key.

Final Step#

Submit Carlos’s API key to solve the lab:

Conclusion#

This lab clearly demonstrates how subtle discrepancies between cache behavior and server logic can lead to severe security flaws like data leakage. Attackers can exploit these differences by crafting misleading URL paths to cache sensitive content intended for authenticated users. Always ensure your caching logic aligns with your authentication and routing mechanisms.