Lab: Exploiting origin server normalization for web cache deception

Identify a target endpoint

1. In Burp's browser, log in to the application using the credentials wiener:peter.

2. Notice that the response contains your API key.

Investigate path delimiter discrepancies

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

2. Go to the Repeater tab. Change the 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 message and select Send to Intruder.

5. Go to the Intruder tab. Make sure the Sniper attack type is selected and add a payload position after /my-account as follows: /my-account§§abc.

6. Go to the Payloads tab. Under Payload settings [Simple list], add a list of characters that may be used as delimiters. Under Payload encoding, deselect URL-encode these characters.

7. Click Start attack. The attack runs in a new window.

8. When the attack finishes, sort the results by Status code. Notice that only the ? character receives a 200 response with your API key. This indicates that the origin server only uses ? as a path delimiter. As ? is generally universally used as a path delimiter, move on to investigate normalization discrepancies.

Investigate normalization discrepancies

1. In Repeater, remove the arbitrary abc string and 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 200 response with your API key. This indicates that the origin server decodes and resolves the dot-segment, interpreting the URL path as /my-account.

3. In Proxy > HTTP history, notice that the paths for static resources all start with the directory prefix /resources. Notice that responses to requests with the /resources prefix show evidence of caching.

4. Right-click a request with the prefix /resources and select Send to Repeater.

5. In Repeater, add an encoded dot-segment after the /resources path prefix, such as /resources/..%2fYOUR-RESOURCE.

6. Send the request. Notice that the 404 response contains the X-Cache: miss header.

7. Resend the request. Notice that the value of the X-Cache header changes to hit. This may indicate that the cache doesn't decode or resolve the dot-segment and has a cache rule based on the /resources prefix. To confirm this, you'll need to conduct further testing. It's still possible that the response is being cached due to a different cache rule.

8. Modify the URL path after /resources to a arbitrary string as follows: /resources/aaa. Send the request. Notice that the 404 response contains the X-Cache: miss header.

9. Resend the request. Notice that the value of the X-Cache header changes to hit. This confirms that there is a static directory cache rule based on the /resources prefix.

Craft an exploit

1. Go to the Repeater tab that contains the /aaa/..%2fmy-account request. Attempt to construct an exploit as follows: /resources/..%2fmy-account. Send the request. Notice that this receives a 200 response with your API key and the X-Cache: miss header.

2. Resend the request and notice that the value of the X-Cache header updates to hit.

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

4. In the Body section, craft an exploit that navigates the victim user carlos to a malicious URL. Make sure to add an arbitrary parameter as a cache buster, so the victim doesn't receive your previously cached response:

   <script>document.location="https://YOUR-LAB-ID.web-security-academy.net/resources/..%2fmy-account?wcd"</script>

5. Click Deliver exploit to victim. When the victim views the exploit, the response they receive is stored in the cache.

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

   https://YOUR-LAB-ID.web-security-academy.net/resources/..%2fmy-account?wcd

7. Notice that the response includes the API key for the user carlos. Copy this.

8. Click Submit solution, then submit the API key for carlos to solve the lab.