Web Cache Poisoning via POST Request
Description
This vulnerability occurs when a web application's caching system can be manipulated to store malicious content by exploiting inconsistencies in how cache keys are generated. Specifically, when a POST request is sent with parameters that match a cached GET request's URL, the caching layer may incorrectly serve or store the POST response using the GET request's cache key. This allows an attacker to inject malicious content into the cache, which is then served to subsequent users requesting the same resource.
Remediation
Implement the following measures to prevent web cache poisoning via POST requests:
1. Include HTTP method in cache keys: Ensure your caching configuration differentiates between HTTP methods (GET, POST, PUT, etc.) when generating cache keys. Responses from POST requests should never be cached using the same key as GET requests.
Example Varnish VCL configuration:
sub vcl_hash {
hash_data(req.url);
hash_data(req.http.host);
hash_data(req.method);
return (lookup);
}Example Nginx configuration:
proxy_cache_key "$scheme$request_method$host$request_uri";
2. Disable caching for POST requests: In most cases, POST request responses should not be cached at all, as they typically involve state-changing operations.
3. Validate cache configuration: Review your caching layer (CDN, reverse proxy, or application cache) to ensure it properly handles different HTTP methods and does not allow method-based cache confusion.
4. Implement cache-control headers: Use appropriate Cache-Control headers (e.g., 'no-store' for sensitive or dynamic POST responses) to prevent unintended caching.