HTTP Cache Poisoning and Host Header Injection

Thursday, June 12, 2008

A recent post came through the WASC mailing list today from Carlos Bueno regarding this topic. The basic gist is in the impact of utilizing the browser-supplied Host headers as a means for link consistency in programming your web code.

For example, assume the page ‘urltest.php’ contained the following

$host = $_SERVER['HTTP_HOST'];
$filename = $_SERVER["REQUEST_URI"];
echo 'http://'.$host.$filename;

Although a simple example, imagine using this variable as the root of any “a href” links you may want to make (by the way, it seems to be the default for PHP5 installations I’ve tested)

The problem lies in the ability for an attacker to arbitrarily change the Host: header information when talking to your web server. For example:

nc 80
GET /urltest.php HTTP/1.1
User-Agent: Mozilla

which results in the following HTML output from the server

HTTP/1.1 200 OK
Date: Thu, 12 Jun 2008 19:42:23 GMT
Server: Apache
X-Powered-By: PHP/5.1.6
Content-Length: 41
Connection: close
Content-Type: text/html; charset=UTF-8

…returning the invalid Host header in our echo statement which was provided by the attacker.

The theoretical problem here lies in the ability in certain isolated situations to poison the server’s cache or poison an upstream proxy cache, which could mean an attacker could redirect links or other content embedded in the attacked site, while other users browse the vulnerable page….

I actually verified this in a couple of instances today on some real servers and it works, but while going through my Squid Proxy (in an attempt to capitalize on the cache-poisoning issue), Squid properly returned the valid host headers, even when I cleared the cache, so this is probably a very low-risk attack from a proxy cache-poisoning perspective, but I bet the method has other uses (we already do similar things when attempting HTTP Response-Splitting)

In shared hosting environments, it is possible to use this attack to force your browser to grab resources from another virtual host on the same server. I tested this on a shared server with 2 known virtual hosts, and found that by inserting an initial “Host:” variable referencing another host in my shared server, all subsequent calls would reference resources on the other domain (for example includes and images) where full paths where not used in the source code.

For example:

include 'file.php'

Would attempt to load the file ‘file.php’ from the forged host header running on the same machine…

I tested this on an Apache2/PHP5 installation running on Linux with 2 virtual host defs….works every time…I can swap include files for my own to run my own content…

If you have a web server on a shared (i.e. virtual) environment, you are at risk

Vulnerabilities Webappsec->General
Post Rating I Like this!
avelin injector