Host Header injection is not the type of attack that you would normally find in CTFs or security challenges. However, it is largely widespread in the wild web. It is also not very difficult to exploit once you encounter a vulnerable web server, as this article will later show.

Before we get to the offensive part, let’s first start by understanding what is a Host Header, and what it does.

The HTTP Host Header

The Host Header is a mandatory field that web clients should include in their HTTP requests. It indicates to the webserver which domain the client is trying to connect to. This can be useful in situations where multiple websites are hosted on the same web server. They can share the same IP address but differ in the domain name.

Here is what an HTTP request with a Host header should look like:

GET /index.html HTTP/1.1
Host : patchthenet.com

Web applications are generally not hosted on standalone servers. Rather, you will most often find them running on top of a shared server. These applications will therefore be sharing the same IP address. And so, to differentiate between where incoming requests are destined, the web server will rely on the HTTP host header.

On the other hand, some websites may only be accessible through an intermediary system that handles the traffic from the client. These systems may be load balancers, reverse proxies, or WAFs. In this case, all these websites will share a single IP address. And once again, the HTTP host header will come to the rescue to help route the requests to their intended destinations.

Well, now that we have seen the utility of this header, let’s go ahead and see how this can pose a risk to the security of web applications.

HTTP Host Header Injection Attacks

Sometimes, web applications need to know the domain in which they are hosted. This is particularly true when they need to reference a resource through an absolute path.

In such situations, a web application will normally get this domain name from the HTTP Host Header value.

Here is an example of how a web application can achieve this:

<a href="http://<?php echo $_SERVER['Host']; ?>/absolute/path/to/a/resource">Link</a>

Behind this seemingly harmless line, there is a major vulnerability that may not be obvious at first.

The web application will retrieve the Host Header value: $_SERVER['Host'], and inserts it in its code.

However, as we’ve previously seen, this value is user-controllable. Meaning that a user can modify it before sending their request.

An attacker can simply inject a malicious payload as the Host Header value, and the web application will inadvertently process it and execute it.

X-Forwarded-Host

Another way to change the Host Header Value is by using X-Forwarded-Host. Proxies use this header to forward HTTP requests to the web server while keeping the original Host value that the web browser has provided.

An attacker can use this header with a malicious payload to override the Host Header.

GET /index.html HTTP/1.1
Host : patchthenet.com
X-Forwarded-Host : malicious.com

By taking the previous example, and changing the Host variable with the above value, we will get the following:

<a href="http://malicious.com/absolute/path/to/a/resource">Link</a>

An attacker can use the Host Header as a way that leads to various types of attacks. Most commonly, attackers will inject the Host header in order to achieve web cache poisoning, SSRF, or password reset poisoning.

Exploitation

Once you find a vulnerable website, it is actually straightforward to exploit it. Using a local proxy, you can intercept your request to the website before it leaves your machine.

For instance, the image below shows the intercepted request to my website using Burp:

Now, the attacker can simply change the Host Header value, where it says: www.patchthenet.com, with a domain name that they control. And then, they can forward the request.

Of course, this will not work here, and it won’t be effective against most websites as well, because there are many security controls that web administrators implement in order to protect their websites against these attacks.

And this is what we are going to cover next.

Preventing Host Header Injection Attacks

Fortunately, Host header injection attacks are not unavoidable. By following certain security measures, you can protect your web application and mitigate the risk of an HTTP Host Header attack occurring.

The safest and most secure measure that you can set in place is to avoid using the HTTP Host Header in the first place. You should always ask yourself if you really need to include absolute paths when calling resources.

When you really need to rely on Host headers, then you should make sure to validate the Host Header as you would for any other user-provided input.

You should also consider checking the HTTP Host Header against a whitelist of known domains. The web application will only process domain names that are present in the whitelist.