HTTP header reflected in cached response
Description
This web application uses a caching mechanism that stores HTTP responses for improved performance. A vulnerability exists where the application reflects certain HTTP header values in its responses without properly accounting for them in the cache key. This allows an attacker to manipulate cached content by sending requests with crafted header values that become part of the cached response, which is then served to subsequent users requesting the same resource.
Remediation
Implement one or more of the following mitigations to prevent cache poisoning through reflected headers:
1. Include reflected headers in the cache key: Configure your caching system to incorporate any HTTP headers that are reflected in responses as part of the cache key. This ensures that responses with different header values are cached separately.
2. Remove or sanitize reflected headers: Avoid reflecting user-controlled HTTP headers in responses. If reflection is necessary, properly encode or sanitize the header values before including them in the response.
3. Implement cache key normalization: Configure your cache to use a normalized cache key that includes all varying headers. For example, in Varnish:
sub vcl_hash {
hash_data(req.url);
hash_data(req.http.host);
# Include the reflected header in cache key
if (req.http.X-Reflected-Header) {
hash_data(req.http.X-Reflected-Header);
}
return (lookup);
}4. Use the Vary header: Set appropriate Vary response headers to indicate which request headers affect the response content, helping caches understand when to serve different versions.
5. Disable caching for dynamic content: If the response varies based on user input, consider disabling caching entirely using appropriate Cache-Control headers (e.g.,
Cache-Control: no-store, private).