The thing with host header injection is that it can allow an attacker to control part of a response. From a great article at Acunetix:
The PHP script in the following example is a typical and dangerous use of the host header.
<script src="http://<?php echo _SERVER['HOST'] ?>/script.js">
An attacker can potentially manipulate the code above to produce the following HTML output just by manipulating the host header.
<script src="http://attacker.com/script.js">
But if you are only manipulating the response you get yourself, this isn't very useless. After all, XSS:ing yourself isn't that fun. You need to change the response your victim get, but you can't modify the host header of your victims request. Whats to do? There are two common ways:
- Cache poisoning: If the response that loads a script from
attacker.com is cached at some server, it will be served to others as well. Bingo!
- Password reset: If you can modify the password reset link that is sent out in emails, you can steal the password reset token once the victim clicks it. (Note that this is not modifying the HTTP response, but rather an email the server sends.)
So if none of this works, does that mean everything is good and well? Not really. It probably mean that this can't be exploited at the moment, at least not in an easy way, but it is still bad and something that should be reported in a pentest report. Because what happends if someone changes the chache policy one day? You don't want to be just a server reconfig away from getting owned.
