Web Cache Poisoning DoS
Description
This vulnerability occurs when a web cache system is misconfigured to cache HTTP error responses (such as 400 Bad Request or 501 Not Implemented). An attacker can exploit this by sending a malformed request to a legitimate resource, causing the server to return an error response that gets cached. Once cached, all subsequent users requesting that resource will receive the cached error response instead of the legitimate content, effectively denying access to the resource.
Remediation
Configure the caching system to exclude error responses from being cached. Implement the following measures:
1. Configure cache rules to only cache successful responses (2xx and 3xx status codes). Explicitly exclude 4xx and 5xx error responses from caching.
2. For CDN or reverse proxy configurations (e.g., Nginx, Varnish, CloudFlare), set cache control headers appropriately:
# Nginx example
proxy_no_cache $error_status;
map $status $error_status {
~^[45] 1;
default 0;
}
3. In application code, set explicit cache control headers for error responses:
// Example for error responses
response.setHeader("Cache-Control", "no-store, no-cache, must-revalidate");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "0");
4. Implement cache key normalization to prevent malformed requests from generating unique cache entries for the same resource.
5. Review and test cache configuration thoroughly, particularly focusing on how error conditions are handled across different request types and headers.