This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Cache Poisoning
- This is an Attack. To view all attacks, please see the Attack Category page.
- This article includes content generously donated to OWASP by
Description
The impact of a maliciously constructed response can be magnified if it is cached either by a web cache used by multiple users or even the browser cache of a single user. If a response is cached in a shared web cache, such as those commonly found in proxy servers, then all users of that cache will continue receive the malicious content until the cache entry is purged. Similarly, if the response is cached in the browser of an individual user, then that user will continue to receive the malicious content until the cache entry is purged, although only the user of the local browser instance will be affected.
To successfully carry out such an attack we shall do the following:
- Find the vulnerable service code, which allows us to fill the HTTP header field with many headers.
- Force the cache server to flush its actual cache for the content, which we want be cached by the servers.
- Send specially crafted request created by the attacker, which will be stored in cache.
- Send the next request. The previously injected content stored in cache, will be the response to this request.
Described attack is rather difficult to carry out in the real environment. The list of conditions is long and hard to accomplish by the attacker. However it's easier to use this technique than Cross-User Defacement.
Cache Poisoning attack is possible because of HTTP_Response_Splitting and flaws in the web application. It is crucial from the attacker's point of view that the application allows for filling the header field with more than one header using CR (Carrige Return) and LF (Line Feed) characters.
Examples
Related Threats
Related Attacks
Related Vulnerabilities
Category:Input Validation Vulnerability
