HTTP Cache Poisoning via Host Header Injection

HTTP Cache Poisoning via Host Header Injection

  April 22, 2020    Davinder

---

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.1
Host: 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.