4 ms·
HTTP Cache Poisoning via Host Header Injection
- Andys 18y agoI 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 18y agoI'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 18y agoYeah, 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 18y agoIt 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.
- pmjordan 18y agoUsing a HTTP 301 response to redirect to the correct hostname may also help with your google rank.
- bluelu 18y agoInteresting. 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.
- anonym 18y ago"<a href="http://evilsite.com#/about 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.
- tectonic 18y agoThis 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.