Gotta Cache Em All: Bending the Rules of Web Cache Exploitation

Gotta Cache Em All: Bending the Rules of Web Cache Exploitation

Speakers: Unknown, Unknown, Unknown

Conference: Black Hat USA

YouTube: https://www.youtube.com/watch?v=9gvxEhugnVM

Overview

This talk, "Gotta Cache 'em all: Bending the Rules of Web Cache Exploitation," presented at Black Hat USA, delves into the critical security implications arising from discrepancies in how web cache proxies and origin servers parse URLs. The speaker highlights how these subtle differences can be leveraged by attackers to achieve significant vulnerabilities, ranging from the theft of sensitive user information through web cache deception to arbitrary web cache poisoning and ultimately, full website defacement. The core premise revolves around exploiting the "static extension rule" commonly employed by Content Delivery Networks (CDNs) and other caching mechanisms, combined with an origin server's unique URL handling, particularly its interpretation of path parameters.

The presentation provides a detailed breakdown of how web caches function, the role of cache keys, and the rules governing content storage. It then meticulously walks through an attack scenario, building upon prior research, to illustrate how an attacker can manipulate these parsing differences to force a cache to store sensitive, user-specific data under a seemingly static resource key. While the speaker's identity is not provided in the metadata, the depth of technical explanation underscores a strong grasp of web infrastructure and security. This talk is highly relevant for web developers, security professionals, and anyone involved in managing web infrastructure, especially those utilizing CDNs or implementing custom caching solutions, as it exposes fundamental flaws that can lead to widespread data breaches and service disruptions.

Background

▶ Watch: Introduction to web cache exploitation and agenda (0:00)

Modern web applications extensively leverage web caches to enhance performance and scalability. These caches, often implemented as Content Delivery Networks (CDNs) like Cloudflare, Cloudfront, or Akamai, or even integrated directly into HTTP servers, sit between the client and the origin server. Their primary function is to store copies of frequently requested resources, reducing the load on the origin server and delivering content faster to users. The process begins when a client sends an HTTP request. The cache proxy intercepts this request and calculates a cache key, which is a unique identifier typically derived from the URL and the Host header. This key determines which resource is being requested. If a response for that key is already stored in the cache, it's served directly to the client.

If the resource is not found in the cache, the request is forwarded to the origin server. The origin server then parses the URL to identify the requested path and map it to an appropriate endpoint, which could be a dynamic application or a static file. After generating a response, the origin server sends it back to the cache proxy. At this stage, the cache proxy evaluates both the request and the response to decide if the resource should be cached. This decision is influenced by several factors, including the Cache-Control HTTP header sent by the origin server, which provides directives on caching behavior, and internal rules configured within the cache proxy itself.

A prevalent caching rule, particularly in CDNs, is the static extension rule. This rule dictates that if the path of a request ends with a recognized "static extension" (e.g., .js, .css, .png, .jpg, .gif, .svg, .ico, .woff, .ttf, .otf, .eot, .json, .xml, .pdf), the corresponding response should be considered static and cached. For instance, Cloudflare, as mentioned by the speaker, applies a default set of such extensions. This mechanism is efficient for static assets but creates a critical vulnerability when combined with disparate URL parsing logic between the cache proxy and the origin server.

The foundation for these types of attacks was significantly advanced by Omar Gill's presentation at Black Hat 2017. Gill's work highlighted that some backend servers interpret parts of the URL path as path parameters, where only the initial segment of the URL is used to identify the endpoint, and subsequent segments are treated as parameters rather than part of the resource path. For example, a request to myaccount/param1/param2 might resolve to the myaccount endpoint on the origin server, with param1 and param2 being handled as input parameters. This difference in interpretation — where the cache proxy sees a full path that might end in a static extension, while the origin server sees a shorter path with additional parameters — creates the exploitable discrepancy. This talk builds upon this prior work, demonstrating how these parsing differences can be exploited to "bend the rules" of web cache behavior, leading to sophisticated attacks.

Key Findings

▶ Watch: Common static extension caching rule (2:30)

The talk uncovers critical vulnerabilities stemming from the fundamental mismatch in URL parsing logic between frontend cache proxies (like CDNs) and origin servers. The primary findings demonstrate how attackers can exploit these discrepancies to achieve three significant attack outcomes: arbitrary web cache deception, web cache poisoning, and ultimately, full website defacement.

The most detailed finding, thoroughly explained in the presentation, focuses on web cache deception. This attack leverages the combination of an origin server's interpretation of path parameters and a cache proxy's static extension rule. The key discovery is that a malicious actor can craft a URL that, to the origin server, points to a sensitive, user-specific endpoint (e.g., a user's account page containing personal data like email or credit card information). However, to the cache proxy, this same URL appears to be a request for a static resource due to a forged file extension (e.g., .js, .css) appended as a path parameter. By enticing a victim to visit this specially crafted link while logged into their account, the attacker can force the cache proxy to store the victim's sensitive, personalized response under a static cache key. Subsequently, the attacker can retrieve this cached response, thereby stealing the victim's data.

Building upon this core deception mechanism, the speaker outlines the potential for web cache poisoning. While the detailed technical steps for poisoning are not as explicitly elaborated in the provided transcript as the deception attack, the finding is that similar URL parsing discrepancies can be abused to manipulate the cache key itself. This allows an attacker to store arbitrary, attacker-controlled content under a cache key that a legitimate user would later request. For example, an attacker could cache a malicious JavaScript file or a defaced webpage in place of a legitimate one.

The ultimate finding is the ability to combine these techniques for full website defacement. By first achieving web cache poisoning, where an attacker can replace legitimate content with their own, and potentially using deception to target specific user experiences, an attacker could effectively take over the cached version of a website. This means that subsequent visitors requesting the "legitimate" pages would instead be served the attacker's malicious or defaced content from the cache, leading to a complete compromise of the user-facing application's integrity. These findings underscore a systemic issue in how web infrastructure components interact, highlighting the danger when their underlying parsing logic is not perfectly synchronized.

Technical Deep Dive

▶ Watch: URL parsing discrepancies vulnerability explained (3:50)

The technical core of the vulnerabilities discussed lies in the divergent ways URL parsing is handled by web cache proxies and origin servers. This discrepancy allows an attacker to craft a single URL that means two different things to these two crucial components of the web stack.

Let's first understand the standard operation of a web cache. When a client sends an HTTP request, it first hits the cache proxy. The proxy calculates a cache key, which is typically a combination of the URL and the Host header. This key is used to look up if the requested resource is already stored. If not, the request is forwarded to the origin server. The origin server then processes the URL to determine the requested endpoint. Crucially, the origin server also dictates caching behavior through the Cache-Control header in its response. However, many cache proxies, especially CDNs like Cloudflare, Cloudfront, or Akamai, also apply their own internal rules. A common rule is the static extension rule: if a URL path ends with a known static file extension (e.g., .js, .css, .png), the cache proxy assumes the resource is static and caches the response. Cloudflare, for instance, by default caches resources ending in extensions like .js, .css, .jpg, .png, .gif, .svg, .ico, .woff, .ttf, .otf, .eot, .json, .xml, .pdf.

The attack scenario, building on Omar Gill's 2017 research, specifically exploits origin servers that treat certain parts of the URL path as path parameters. Consider an application where the URL /myaccount/profile.json might retrieve a user's profile. If the origin server is configured to parse /myaccount as the endpoint and anything following as optional parameters, then a request to /myaccount/param1/param2 would still resolve to the myaccount endpoint. The param1 and param2 segments would be ignored or processed as application-level parameters, not as part of the resource's file path.

The web cache deception attack unfolds as follows:

1. Attacker Crafts Malicious URL: The attacker identifies a sensitive endpoint on the target website, for example, /myaccount, which, when accessed by a logged-in user, returns personalized, sensitive information (e.g., email address, credit card details). The attacker then crafts a URL like https://example.com/myaccount/sensitivedata.js.

• To the origin server: The server parses /myaccount as the intended endpoint. The /sensitivedata.js part is treated as a path parameter and effectively ignored in terms of endpoint resolution. Since the victim is logged in, the origin server retrieves and returns the victim's sensitive account information.
• To the cache proxy: The proxy observes that the URL path /myaccount/sensitivedata.js ends with the .js extension. According to its static extension rule, it determines that this response should be cached as a static resource.

1. Victim Interaction: The attacker sends this malicious link to a victim. When the victim, who is logged into example.com, clicks on the link, their browser sends the request along with their authentication cookies.

1. Cache Population:

• The cache proxy receives the request. Since it doesn't have https://example.com/myaccount/sensitivedata.js in its cache, it forwards the request to the origin server.
• The origin server processes /myaccount using the victim's cookies and returns a response containing the victim's sensitive data (e.g., a JSON object with email and credit card info, or an HTML page displaying it).
• The cache proxy receives this response. Due to the .js extension in the URL it originally processed, it caches this sensitive, personalized response under the cache key for https://example.com/myaccount/sensitivedata.js.

1. Attacker Retrieves Sensitive Data: The attacker then simply requests https://example.com/myaccount/sensitivedata.js. Since this resource is now cached, the cache proxy serves the previously stored response, which contains the victim's sensitive information. This constitutes arbitrary web cache deception, as the attacker has "deceived" the cache into storing private user data as a public static asset.

While the transcript primarily focuses on the detailed mechanism of web cache deception, it also outlines the potential for web cache poisoning and full website defacement using "similar techniques." The underlying principle for these advanced attacks would still involve exploiting URL parsing discrepancies to manipulate the cache's decision-making. For cache poisoning, an attacker would aim to replace a legitimate, frequently accessed resource (e.g., /styles.css or /index.html) with attacker-controlled content. This could be achieved by crafting a URL that, to the cache proxy, looks like the legitimate resource, but to the origin server, triggers a response that the attacker can control (e.g., an error page with injected content, or a redirect to an attacker-controlled server). The key would be to ensure the cache proxy still deems the response cacheable under the legitimate resource's key, effectively poisoning the cache.

Full website defacement would be the culmination of successful cache poisoning. By poisoning multiple critical assets (HTML, CSS, JavaScript files), an attacker could entirely alter the appearance and functionality of the website for users served from the cache. This could involve replacing the homepage with a defaced version, injecting malicious scripts (e.g., for phishing or malware distribution), or redirecting users to malicious sites. The effectiveness of these attacks relies heavily on the specific URL parsing logic of both the cache proxy and the origin server, and the rules governing cacheability. The speaker emphasized that these attacks are applicable to a wide range of web caches, not just specific CDNs, highlighting a pervasive architectural vulnerability.

Demo / Proof of Concept

▶ Watch: Omar Gill's Web Cache Deception attack (4:15)

The talk walked through detailed conceptual steps for the web cache deception attack, outlining how a malicious link would be crafted and how a victim's interaction would lead to the caching of their sensitive data. The speaker used the example of myaccount/a.js to illustrate how the origin server would interpret myaccount as the endpoint and a.js as a parameter, while the cache proxy would see the .js extension and decide to cache the response. This step-by-step breakdown clearly demonstrated the attack flow from an attacker's perspective to the victim's interaction and the subsequent data retrieval.

While the presentation did not describe a live demonstration of code or a specific tool being used, the conceptual walk-through served as a clear proof of concept. The explanation included the structure of the malicious URL, the role of the victim's cookies, the origin server's processing, and the cache proxy's caching decision, culminating in the attacker's ability to retrieve the cached sensitive information. The explicit mention of CDNs like Cloudflare, Cloudfront, and Akamai, and the default static extensions used by Cloudflare, grounded the theoretical attack in real-world scenarios.

Defensive Implications

▶ Watch: Step-by-step Web Cache Deception demonstration (4:40)

The provided transcript unfortunately concludes before reaching the section specifically dedicated to defensive implications, despite it being listed in the talk's initial agenda. Therefore, based solely on the supplied text, specific defense strategies articulated by the speaker are not available.

However, based on the nature of the described attacks, several general defensive strategies can be inferred to mitigate the risks posed by URL parsing discrepancies and web cache exploitation:

1. Synchronize URL Parsing Logic: The most fundamental defense is to ensure that the URL parsing logic of the cache proxy and the origin server are perfectly synchronized. Any discrepancy, especially regarding what constitutes a path versus a parameter, can be exploited. Developers and system administrators should thoroughly understand how both their CDN/cache and their backend application framework interpret URLs, paying close attention to trailing slashes, encoded characters, and how path segments are handled.
2. Strict Cache-Control Headers: Origin servers should use explicit and restrictive Cache-Control headers for sensitive or dynamic content. Responses containing user-specific information should always include Cache-Control: private, no-store or at least Cache-Control: no-cache to prevent any proxy from storing them. For static assets that are genuinely public, appropriate Cache-Control: public, max-age=... headers can be used.
3. Avoid Caching Dynamic/Sensitive Endpoints: Cache configurations should explicitly prevent caching for endpoints known to serve dynamic or user-specific content, regardless of file extensions. This might involve whitelisting specific paths for caching (e.g., /assets/*) rather than relying solely on file extensions or blacklisting sensitive paths.
4. Careful Handling of Path Parameters: If the origin server uses path parameters, ensure that these do not inadvertently create paths that the cache proxy might interpret as static resources. It might be safer to use query parameters for variable data rather than path segments that could be confused with file extensions.
5. Review CDN/Cache Rules: Regularly review and customize the default caching rules provided by CDNs or other cache solutions. Do not blindly rely on default static extension lists; ensure they align precisely with the application's actual static assets and that no sensitive endpoints could be accidentally caught by these rules.
6. Parameter-Based Cache Keys: For certain dynamic resources that can be safely cached, consider configuring the cache to include specific query parameters in the cache key. This ensures that different responses based on these parameters are stored separately, preventing pollution across different user contexts.
7. Security Audits and Testing: Conduct regular security audits and penetration testing specifically targeting cache-related vulnerabilities. Tools like Burp Suite's Cache Killer or specialized cache analysis plugins can help identify discrepancies and potential attack vectors.
8. Web Application Firewall (WAF) Rules: Implement WAF rules to detect and block suspicious requests that attempt to exploit URL parsing discrepancies, such as requests to sensitive endpoints with unusual file extensions appended.

By implementing these measures, organizations can significantly reduce their exposure to web cache deception, poisoning, and defacement attacks, protecting both user data and website integrity.

Key Takeaways

• URL Parsing Discrepancies are Critical: The core vulnerability stems from different interpretations of URLs between web cache proxies (CDNs) and origin servers, particularly regarding path parameters and static file extensions.
• Web Cache Deception Steals Sensitive Data: Attackers can craft URLs that trick a cache proxy into storing a victim's sensitive, personalized information (e.g., email, credit card) under a public cache key, which the attacker can then retrieve.
• Static Extension Rules are a Double-Edged Sword: While useful for performance, default static extension caching rules in CDNs (e.g., Cloudflare's .js, .css lists) can be abused when combined with origin server path parameter handling.
• Cache Poisoning and Defacement are Possible: Building on deception techniques, similar parsing vulnerabilities can lead to web cache poisoning (storing arbitrary attacker-controlled content) and full website defacement for cached versions of a site.
• CDNs and Custom Caches are Vulnerable: The attacks are not limited to specific CDNs but can apply to any web cache where such parsing discrepancies exist, including those integrated into HTTP servers.
• Proactive Defense is Essential: While specific defenses were not detailed in the provided transcript, inferred mitigations include synchronizing URL parsers, strict Cache-Control headers, avoiding caching of dynamic content, and regular security audits.

About the Speaker(s)

The speaker(s) for this Black Hat USA talk, "Gotta Cache Em All: Bending the Rules of Web Cache Exploitation," are listed as "Unknown" in the provided metadata. The transcript does not offer any personal details or professional affiliations beyond the technical content presented.