It is common practice for the same web server to host several websites or web applications on the same IP address. This why the host header exists. The host header specifies which website or web application should process an incoming HTTP request. The web server uses the value of this header to dispatch the request to the specified website or web application. Each web application hosted on the same IP address is commonly referred to as a virtual host. So what constitutes a host header attack?
What happens if we specify an invalid Host Header? Most web servers are configured to pass the unrecognized host header to the first virtual host in the list. Therefore, it’s possible to send requests with arbitrary host headers to the first virtual host.
Another way to pass arbitrary Host headers is to use the X-Forwarded-Host header. In some configurations this header will rewrite the value of the Host header. Therefore it’s possible to make the following request.
GET / HTTP/1.1
Host: www.example.com
X-Forwarded-Host: www.attacker.comMany web application rely on the HTTP host header to understand “where they are”. Unfortunately, what many application developers do not realize is that the HTTP host header is controlled by the user. As you might already know, in application security user input should always be considered unsafe and therefore, never trusted without properly validating it first.
The use of the host header is especially common in PHP web applications, however, it’s certainly not a problem endemic to PHP web applications. 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">The two major attack vectors host header attacks enable are web-cache poisoning, and abuses of alternative channels for conducting sensitive operations, such as password resets.
Web-cache poisoning
Web-cache poisoning is a technique used by an attacker to manipulate a web-cache to serve poisoned content to anyone who requests pages.
For this to occur, an attacker would need to poison a caching proxy run by the site itself, or downstream providers, content delivery networks (CDNs), syndicators or other caching mechanisms in-between the client and the server. The cache will then serve the poisoned content to anyone who request it, with the victim having no control whatsoever on the malicious content being served to them.
The below is an example of how an attacker could potentially exploit a host header attack by poisoning a web-cache.
$ telnet www.example.com 80
Trying x.x.x.x...
Connected to www.example.com.
Escape character is '^]'.
GET /index.html HTTP/1.1
Host: attacker.com
HTTP/1.1 200 OK
...
<html>
<head>
<title>Example</title>
<script src="http://attacker.com/script.js">
...Password Reset Poisoning
A common way to implement password reset functionality is to generate a secret token and send an email with a link containing this token. What could happen if an attacker requests a password reset with an attacker controlled host header?
If the web application makes use of the host header value when composing the reset link, an attacker can poison the password reset link that is sent to a victim. If the victim clicks on the poisoned reset link in the email, the attacker will obtain the password reset token and can go ahead and reset the victim’s password.
Mitigation
Mitigating against host header is simple — don’t trust the host header. However in some cases, this is easier said than done (especially situations involving legacy code). If you must use the host header as a mechanism for identifying the location of the web server, it’s highly advised to make use of a whitelist of allowed hostnames.
Frequently asked questions
A Host header attack, also known as Host header injection, is a web attack where the attacker provides a false Host header to the web application.
Find more information about other types of injection attacks.
According to the latest Acunetix Web Application Vulnerability Report, Host header injection is becoming less common but still present in approximately 2.5% of web applications.
Host header attacks may be used for web cache poisoning and attacks such as password reset poisoning. Web cache poisoning lets an attacker serve poisoned content to anyone who requests pages. Using password reset poisoning, the attacker can obtain a password reset token and reset another user’s password.
The most efficient way to detect Host header vulnerabilities is by using a professional web vulnerability scanner such as Acunetix. Acunetix will not only detect all kinds of vulnerabilities and misconfigurations but will also suggest ways to resolve them and you can use it to manage the repair process.
To avoid Host header attacks, simply don’t trust the Host header. If you must use the Host header to identify the location of the web server, use a whitelist of allowed hostnames.
Read more about secure coding practices for web applications.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
