HTTP Cache Poisoning via Host Header Injection
Vulnerability:
Rewriting of links and URLs in cached pages to arbitrary strings by
unauthenticated HTTP clients.When the application reflects HTTP Header
value back in it's response and it may be possible to poison the server
cache. The X-Forwarded-Host
is directly reflected as a hyperlink. Than Host Header Attack - Cache Poisoning vulnerability may be there like:
Affected software: ANY site that does not validate HTTP Host: headers.
It is common practice for web programmers and web frameworks to rely on
the value of the HTTP Host header to write links. This is for
convenience, so that the same software will run on localhost, various
testing servers, subdomains, secondary domains, etc, without
modification. For example:
<a href="<?=$_SERVER['HTTP_HOST']?>/login">Login</a>
This turns out to be a very, very bad idea in any language. The HTTP Host header is arbitrary text controlled by the client, but common practice treats it as though it were a safe environment variable.
HTTP Request
GET / HTTP/1.1Host: davindertutorials.com
X-Forwarded-Host: test.com
...
....
HTTP Response
HTTP/1.1 200 OK....
....
....
<li class="SL_hide" title="Get New Relic on your iPad, iPhone, or Android phone"><a href="http://test.com/mobility">New Relic for iOS & Android</a></li>
....
Now as you see we are able to see test.com in the response.
Mitigation: DO NOT use the value of the Host header for anything. If you must, apply very strict filters to only allow valid FQDNs, and then whitelist the FQDNs you allow. Treat it as you would any arbitrary data coming from the outside. If your webserver is configured to output the value of the Host header (as in the example, and as by default in many webservers), disable that configuration.
0 comments:
Post a Comment