

HTTP Cache Poisoning via Host Header Injection - aristus
http://carlos.bueno.org/2008/06/host-header-injection.html

======
tectonic
This is definitely a real issue, I was able to demonstrate cache poisoning in
my Rails app because a plugin does this. I fixed it by only caching pages with
explicitly valid Host headers, and by re-writing the Host header in nginx if
it looks invalid.

------
bluelu
Interesting. At I first I thought that the poisened url would only affect my
own session and would be pretty useless with https, but combined with caching,
it is definitely a very interesting approach.

------
Andys
I think this is legit. But it only really affects servers or infrastructure
that employ caching.

The fix is simple - validate the contents of the Host field at the start of a
request

~~~
Andys
I've learned that there is another fix - use name-based virtual hosting so
that your webserver won't accept bogus host names as pointing to your
application.

~~~
jrockway
Yeah, and this is the main reason nobody has noticed (or cared) about this.
Since your app isn't dispatched to unless "Host" makes sense, it doesn't
really matter. (Does anyone _not_ use name-based virtual hosting?)

~~~
aristus
It is definitely an issue. I agree that many sites are not vulnerable, but too
many are by default, including many popular web frameworks, and many, many,
many hosts that are on dedicated IP addresses and configured to answer to any
host.

------
anonym
"<a href="<http://evilsite.com#/about>">About</a>"

There is absolutely no reason to build links with your own hostname in them in
the first place. Why on earth would you make a link like this instead of
href="/about"?

edited to add: the spec says that the Location header for a redirect must be
an absolute URI, so that's one case where you'd need to know your hostname.
But you certainly don't need it to build links.

