Web Cache Deception

Web Cache Deception

These preconditions can be exploited for the Web Cache Deception attack in the following manner:

• Step 1: An attacker entices the victim to open a maliciously crafted link:

  https://www.example.com/my_profile/test.jpg

  The application ignores the 'test.jpg' part of the URL, the victim profile page is loaded. The caching mechanism identifies the resource as an image, caching it.

• Step 2: The attacker sends a GET request for the cached page:

  https://www.example.com/my_profile/test.jpg

  The cached resource, which is in fact the victim profile page is returned to the attacker (and to anyone else requesting it).

Web Cache Deception

Web Cache Deception is a technique that deceives a web cache proxy to store/steal unexpected data such as user’s sensitive data.

Enumeration

1. Find Pages Containing Sensitive Information

Fist of all, we need to find pages that contain sensitive data to steal. For example,

• User profile page

• API key settings page

If the response contains these secret information, it’s worth to try the web cache deception. Our goal is to steal victim’s information by abusing the cache.

2. Identify Discrepancies

• Path Mapping

  Assume that we’ve found API key settings page (/api). Modify the path for adding the extension (/api/abc.js) and send request, then check if the response content is the same as the /api and look at the value of the X-Cache response header:

  • X-Cache: miss : The response was NOT served from the cache.

  • X-Cache: hit : The response was served from the cache.

  If the X-Cache header does not exist, the website may not be vulnerable to Web Cache Deception. If the X-Cache value is miss, we try to send the same request again and check if the X-Cache value changes to hit. If the X-Cache value becomes hit , it indicates that the response data has been stored into the cache. This means that anyone who sends a request to this path will be able to see what is stored in the cache until expiration.

• Characters Used as Deilimiters

  To find characters that are used as delimiters by the origin server, enumerate characters as below. We can refers the PortSwigger’s awesome list.

  /api!abc.js
  /api"abc.js
  /api#abc.js
  /api?abc.js
  /api%00abc.js
  ...
  
  <!-- URL encoding -->
  /api%21abc.js
  /api%22abc.js
  /api%23abc.js
  /api%3Fabc.js
  ...

• Path Normalization Discrepancies

  If the website serves static files under some directory, we can abuse it:

  /assets/..%2fapi
  /js/..%2fapi
  /static/..%2fapi
  /resources/..%2fapi

Exploit

Guide Victims to Send Request for Storing Data in the Cache

To steal victims sensitive information, we have to guide victims to send request to /api/xxx.js or other path for storing their data. There are several ways to achieve this:

• XSS

• CSRF

• Phishing

In the techniques above, we can craft malicious code to make victims to send request to arbitrary path. Please note that we must not specify the path that we've already sent (e.g. "/profile/api/abc.js" as above) because the response of the path is served from the cache storing our sensitive information, so victims can see them.

<script>document.location="https://vulnerable.com/api/xxx.js"</script>

After the victim sends request to this path, the victim’s sensitive information is stored in the cache, so we can see it by requesting /api/xxx.js.

References

• PortSwigger