ContextQMD
Back to Payloadsallthethings

Web Cache Deception

Web Cache Deception/README.md

4.28.4 KB
Original Source

Web Cache Deception

Web Cache Deception (WCD) is a security vulnerability that occurs when a web server or caching proxy misinterprets a client's request for a web resource and subsequently serves a different resource, which may often be more sensitive or private, after caching it.

Summary

Tools

Methodology

Example of Web Cache Deception:

Imagine an attacker lures a logged-in victim into accessing http://www.example.com/home.php/non-existent.css

  1. The victim's browser requests the resource http://www.example.com/home.php/non-existent.css
  2. The requested resource is searched for in the cache server, but it's not found (resource not in cache).
  3. The request is then forwarded to the main server.
  4. The main server returns the content of http://www.example.com/home.php, most probably with HTTP caching headers that instruct not to cache this page.
  5. The response passes through the cache server.
  6. The cache server identifies that the file has a CSS extension.
  7. Under the cache directory, the cache server creates a directory named home.php and caches the imposter "CSS" file (non-existent.css) inside it.
  8. When the attacker requests http://www.example.com/home.php/non-existent.css, the request is sent to the cache server, and the cache server returns the cached file with the victim's sensitive home.php data.

Caching Sensitive Data

Example 1 - Web Cache Deception on PayPal Home Page

  1. Normal browsing, visit home : https://www.example.com/myaccount/home/
  2. Open the malicious link : https://www.example.com/myaccount/home/malicious.css
  3. The page is displayed as /home and the cache is saving the page
  4. Open a private tab with the previous URL : https://www.example.com/myaccount/home/malicious.css
  5. The content of the cache is displayed

Video of the attack by Omer Gil - Web Cache Deception Attack in PayPal Home Page

Example 2 - Web Cache Deception on OpenAI

  1. Attacker crafts a dedicated .css path of the /api/auth/session endpoint.
  2. Attacker distributes the link
  3. Victims visit the legitimate link.
  4. Response is cached.
  5. Attacker harvests JWT Credentials.

Caching Custom JavaScript

  1. Find an un-keyed input for a Cache Poisoning

    js
    Values: User-Agent
Values: Cookie
Header: X-Forwarded-Host
Header: X-Host
Header: X-Forwarded-Server
Header: X-Forwarded-Scheme (header; also in combination with X-Forwarded-Host)
Header: X-Original-URL (Symfony)
Header: X-Rewrite-URL (Symfony)

  2. Cache poisoning attack - Example for X-Forwarded-Host un-keyed input (remember to use a buster to only cache this webpage instead of the main page of the website)

    js
    GET /test?buster=123 HTTP/1.1
Host: target.com
X-Forwarded-Host: test"><script>alert(1)</script>

HTTP/1.1 200 OK
Cache-Control: public, no-cache
[..]
<meta property="og:image" content="https://test"><script>alert(1)</script>">

Tricks

The following URL format are a good starting point to check for "cache" feature.

  • https://example.com/app/conversation/.js?test
  • https://example.com/app/conversation/;.js
  • https://example.com/home.php/non-existent.css

Detecting Web Cache Deception

  1. Detecting delimiter discrepancies: /path/<dynamic-resource>;<static-resource>
    • For example: /settings/profile;script.js
    • If the origin server uses ; as a delimiter but the cache isn't
    • The cache interprets the path as: /settings/profile;script.js
    • The origin server interprets the path as: /settings/profile
    • For more delimiter characters: see Web cache deception lab delimiter list
  2. Detecting normalization: /wcd/..%2fprofile
    • If the origin server resolved the path traversal sequence but the cache isn't
    • The cache interprets the path as: /wcd/..%2fprofile
    • The origin server interprets the path as: /profile

CloudFlare Caching

CloudFlare caches the resource when the Cache-Control header is set to public and max-age is greater than 0.

In Cloudflare CDN, one can implement a Cache Deception Armor, it is not enabled by default. When the Cache Deception Armor is enabled, the rule will verify a URL's extension matches the returned Content-Type.

CloudFlare has a list of default extensions that gets cached behind their Load Balancers.

7ZCSVGIFMIDIPNGTIFZIP
AVIDOCGZMKVPPTTIFFZST
AVIFDOCXICOMP3PPTXTTFCSS
APKDMGISOMP4PSWEBMFLAC
BINEJSJAROGGRARWEBPMID
BMPEOTJPGOTFSVGWOFFPLS
BZ2EPSJPEGPDFSVGZWOFF2TAR
CLASSEXEJSPICTSWFXLSXLSX

Exceptions and bypasses:

  • If the returned Content-Type is application/octet-stream, the extension does not matter because that is typically a signal to instruct the browser to save the asset instead of to display it.
  • Cloudflare allows .jpg to be served as image/webp or .gif as video/webm and other cases that we think are unlikely to be attacks.
  • Bypassing Cache Deception Armor using .avif extension file - fixed

Labs

References