[WEB SECURITY] HTTP cache poisoning via Host header injection

Michael S. Menefee mmenefee at securesolve.com
Fri Jun 13 00:36:20 EDT 2008


As an additioan to my previous response I've played around with this a
little more

I have tested this on shared hosting environments running apache2/php5

I have an apache2/php5 running on linux server

I created 2 virtual hosts: server1 and server2

I created a PHP file in server1's directory called "test.php" with the
following content:

<?php
Include 'test2.php';
?>

I created "test2.php" with the following content:

<?php
Echo "Blah"
?>

I then used webscarab intercept to call the following:

http://server2

(server2 has an empty directory)

I changed the host header to "Host: server1"

I received the following content:

Blah


So you can use this method in shared hosting environments by taking
advantage of the host header variable




--
Michael S. Menefee, CISSP (#43728)
Principal Consultant
Secure Solve, Inc.
Phone: (919) 439-3598
Fax: (919) 287-2570
mmenefee at securesolve.com
www.securesolve.com

-----Original Message-----
From: Amit Klein [mailto:aksecurity at gmail.com] 
Sent: Thursday, June 12, 2008 4:37 PM
To: Carlos
Cc: websecurity at webappsec.org
Subject: Re: [WEB SECURITY] HTTP cache poisoning via Host header
injection

Carlos wrote:
> I've confirmed this in default installations of a few web frameworks 
> including Rails, Zope and WordPress.
>
> The basic vulnerability comes when:
>
> 1) Your web server does not validate the Host header
> 2) Your code or your framework uses the Host header value to build 
> links
> 3) You employ page or fragment caching
>   

While I do agree this is a security problem, I would like to point out
that:

1. Most platforms I know don't send out caching directives for
dynamically generated pages. Of course, this can be overridden, and
there are probably platforms that allow caching by default, but still...

2. More importantly, a caching HTTP entity will probably cache the page
as http://evilsite.com/foo/bar.html (after all, from the cache server's
perspective, the target host is evilsite.com), thus taking the sting out
of the "cache poisoning" vector. In fact, with forward (and some
transparent) proxy servers, the request will never arrive to
www.example.com - the proxy server will send it to evilsite.com instead.

Thanks,
-Amit

------------------------------------------------------------------------
----
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA



----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA



More information about the websecurity mailing list