Introduction During security tests, a critical vulnerability was discovered in the tested application. This issue allows an attacker to block access to the application. The problem is caused by incorrect cache handling.

Web cache poisoning is an attack where an attacker exploits the caching mechanism to store altered or malicious responses in a cache entry, forcing the website to serve harmful HTTP responses to its users. When improperly implemented, caching mechanisms significantly increase the risk of for example denial of service (DoS) conditions, by serving incorrect cached responses to legitimate users.
How the attack works 1. The attacker intercepts a normal request to the application and injects an X-Forwarded-Host header pointing to a different server domain, such as example.com. The modified request looks as follows: 2. The application responds with an error message (HTTP 400) as follows: Despite headers seemingly indicating that the response should not be cached (no-cache, no-store), due to incorrect cache configuration or misinterpretation of these directives, this error response is still cached by the intermediate caching mechanism.

3. If a normal request, without the manipulated header, is sent to the site shortly after, the previously cached malicious response will be served instead of a proper response, effectively blocking legitimate access for regular users: The server incorrectly returns the cached error: This scenario demonstrates how a single malicious request can disrupt regular user interactions for a period of approximately 5 seconds. Extending the impact through automation Although the cached response only lasts a short period, the attacker can automate and extend the impact indefinitely. For instance, by using automated tools such as Burp Suite Intruder, the attacker can repeatedly inject malicious requests at carefully chosen intervals (for instance, every 5 seconds), ensuring that the cache remains poisoned continuously. This makes the resource permanently unavailable to legitimate users until the attack is mitigated. Recommendations To effectively secure the application against cache poisoning and denial-of-service attacks described above, the following practical measures should be implemented:

1. Include X-Forwarded-Host header in cache key or disable its usage
By ensuring that the cache configuration includes the X-Forwarded-Host header in the cache key generation, each request with manipulated headers will result in separate cache entries, preventing legitimate users from receiving poisoned responses.

2. Prevent caching of error responses
Implement explicit configuration to prevent caching of error pages (such as HTTP status 400). Error responses must always be dynamically generated and should never be stored or served from a cache.

3. Properly validate and sanitize incoming headers

Consider applying strict validation rules and filtering for incoming HTTP headers such as X-Forwarded-Host to prevent malicious header manipulation attempts.