Host Header Injection

Question

I am a beginner in security and reading about the host header injection. I tested an application for this vulnerability and it is possible there for some request but developer implemented no-cache, no-store flags and this vulnerability is not in password reset request.
So first thing is there will not be cache poisoning. and the second is it is not happening in password reset request.
As I understand that for exploiting this vulnerability, I changed that host header. So I want to know why will It be a vulnerability, why a user will change Host of the application? and how an attacker can exploit it?

Answer 1

As in all of the cases the client input on the application should be never trusted (in security terms). The host header attribute is also something that can be changed by the client.

A typical attack scenario would be for example:

Lets suppose you have an application that you blindly trust the HOST header value and use it in the application without validating it. So you may have the following code in your application, where you load a JS file dynamically (by host name):

<script src="http://<?php echo $_SERVER['HOST'] ?>/script.js">

In this scenario, whatever the attacker set as the HOST header would be reflected on this JS script load. So the attacker could tamper with this by manipulating the response to load a JS script from another host (potentially malicious). If the application is using any Caching mechanism or CDN and if this request is repeated multiple times, it can be cached by the Caching Proxy. Then, this can be served to other users as well (as it was saved to cache).

Another way of exploiting this is:

Let suppose that the application has a user password reset feature. And the application will send an email to whoever asks for a password reset with a unique token to reset it, like the email below:

Hi user,
Here is your reset link
http://<?php echo $_SERVER['HOST'] ?>/reset-password?token=<?php echo $token ?>

Now an attacker can trigger a password reset for a known victim email by tampering the HOST header value to the one of his desire. Then the victim would receive the legitimate email for password reset, yet the URL will be changed to the domain set by the attacker. If the victim would open that link, the password reset token could be leaked to the attacker so it would lead to account takeover.