Cache Poisoning

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 to 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, an attacker:

Finds the vulnerable service code, which allows them to fill the HTTP header field with many headers.

Forces the cache server to flush its actual cache content, which we want to be cached by the servers.

Sends a specially crafted request, which will be stored in cache.

Sends the next request. The previously injected content stored in cache will be the response to this request.

This attack is rather difficult to carry out in a 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.

A 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

We have found a web page, which gets its service name from the "page" argument and then redirects (302)
to this service.

In theory, the cache server should match the second answer from the request #2 to the request #3. In this way we've replaced
the cache content.

The rest of the requests should be executed during one connection (if the cache server doesn't require a more sophisticated
method to be used), possibly immediately one after another.

It may appear problematic to use this attack as a universal techique for cache poisoning. It's due to cache server's different
connection model and request proccessing implementations. What does it mean? That for example effective method to poison
Apache 2.x cache with mod_proxy and mod_cache modules won't work with Squid.

A different problem is the length of the URI, which sometime makes it impossible to put the necessary response header, which
would next be matched to the request for the poisoned page.

The request examples used are from [1], which were modified on the needs of the article.