Web Cache Deception: Tricking the Caching Server to Expose Private Data

Introduction

Like web cache poisoning, Web Cache Deception (WCD) is an attack directed against the caching server. The goal of WCD is to trick the caching server into caching the sensitive, private information of other users. In specific scenarios, the exposed information can be used by an attacker to take over a victim’s account.

This exploit relies on two main conditions: path confusion and the fact that some caching servers are aggressively configured to cache requests that appear to be for static files.

Reminder: Web cache deception relies on a fundamental understanding of caching servers. Caching servers save the response to a user’s request and serve that saved response to subsequent users who call the same endpoint, improving performance and reducing server load.

---

Understanding Web Cache Deception

Web cache deception works by crafting a malicious URL that, when visited by a victim, causes the caching server to cache the private response and serve it to everyone, including the attacker.

Condition 1: Overriding Cache Control for Static Files

When a web application handles sensitive data, it typically instructs the caching server not to cache the response. For example, the endpoint /setting.php returns a user’s name, email, address, and phone number. Since the response relies on the user currently logged in, and each response will be different, it would not make sense to cache this page. Furthermore, for security reasons, you absolutely do not want an application caching pages with sensitive information.

The application achieves this by setting the Cache-Control header in the HTTP response:

As seen in the image above, the Cache-Control header is set to no-cache. This explicitly tells the caching server to not cache this page.

However, sometimes the caching server will make an executive decision to cache a page regardless of the response headers. This normally occurs when the caching server is configured to aggressively cache any page ending with a specific extension (such as .css, .jpg, .png, etc.). The caching server is configured to cache all static pages no matter what the response headers say.

Therefore, if an attacker were to request a URL like example.com/nonexistent.css while logged in, the caching server would cache this response, regardless of the actual content or the application’s Cache-Control header, simply because the URL path ends with the .css extension.

Condition 2: Path Confusion

Path confusion occurs when a web application loads the same resources or executes the same logic regardless of slight variations in the requested URL path. With the rise of large web applications and complicated routing tables, this flaw has been unintentionally introduced.

In modern web frameworks, there is often a catch-all path on the root directory. This means that any path after the initial / will essentially be passed to the same function or handler, often resulting in the same response.

In the scenario above, both the example.com/ and example.com/something URLs would be sent to the same catch_all function. While the example only prints the path, in a real-world application, the function would perform some task (like rendering the user’s account page) and return the HTML response.

The following image, taken from the white paper “Cached and Confused: Web Cache Deception in the Wild”, describes several techniques attackers use to achieve path confusion and trick the caching server.

Techniques for Causing Path Confusion:

1. Path Parameter: This occurs when additional path elements added to the request are still passed to the same backend function.
   • Application’s View: example.com/account.php (The application ignores the extra path element and renders the account page.)
   • Caching Server’s View: example.com/account.php/nonexistent.css (The caching server sees the .css extension and decides to cache the resource.)
2. Encoded Newline (%0A): This exploits the difference in how proxies and web servers parse characters. Some web servers stop reading a path after a newline character, but the caching server does not.
   • Application’s View: example.com/account.php
   • Caching Server’s View: example.com/account.php%0Anonexistent.css (The caching server sees the full path with the static extension.)
3. Encoded Semicolon (%3B): Some web servers treat semicolons (;) as parameter separators, while the caching server may not recognize this special meaning.
   • Application’s View: example.com/account.php (The server sees the semicolon and everything after it as a parameter for account.php.)
   • Caching Server’s View: example.com/account.php%3Bnonexistent.css (The caching server sees the full path as a separate resource.)
4. Encoded Pound (%23): Web servers often process the pound character (#) as an HTML fragment identifier and stop parsing the URL after that character, essentially ignoring it in the request sent to the backend. The caching server, however, may not.
   • Application’s View: example.com/account.php
   • Caching Server’s View: example.com/account.php%23nonexistent.css
5. Encoded Question Mark (%3F): Web servers treat question marks (?) as the start of URL parameters, while the caching server may treat the response differently.
   • Application’s View: example.com/account.php (The server sees ?name=valnonexistent.css as a query string for account.php.)
   • Caching Server’s View: example.com/account.php%3fname=valnonexistent.css

As you can tell, the key to these attacks is the difference in interpretation: the web server interprets a request one way (resulting in the user’s private page), while the caching server interprets it a different way (resulting in a cacheable static file).

Executing the Web Cache Deception Attack

The attack is executed by combining the two conditions:

1. The application has a sensitive, authenticated page, like an account setting page (/users/me).
2. The application routing is susceptible to path confusion, or the caching server is configured to ignore Cache-Control for static files.
3. The attacker crafts a malicious URL that exploits the path confusion and ends with a static extension, for example:http://example.com/users/me/profile.css

If a logged-in victim visits this URL, the web server sees the /users/me path and returns the victim’s private information (email, name, phone number, etc.). However, the caching server sees the .css extension and decides to cache the HTML response containing the victim’s private data.

Once the response is cached, the attacker can then simply visit the same URL (http://example.com/users/me/profile.css) and retrieve the cached response, which now contains the victim’s sensitive personal identifiable information (PII).