Host header attacks

What is a Host header attack?

HTTP Host header attacks are any attacks performed by manipulating the value of the Host header in an HTTP request. The attacker sends HTTP requests to a web application or web API and forges the value of the Host header or adds other headers that take precedence over the value of the Host header. This is also often called a Host header injection attack (the name used by OWASP).

What is the function of the Host header?

Web servers usually host several websites or web applications that have different domain names but are accessed via the same IP address. The use of such virtual hosts is what makes the Host request header necessary – the web server uses its value to direct the request to the correct website or web application.

The Host header is a simple text field containing a hostname such as example.com, www.example.com, subdomain.example.com, etc. Here is an example of a legitimate request with a Host header:

GET /samples/snippet.html HTTP/1.1
Host: www.example.com

This request tells the web server to supply the /samples/snippet.html resource located on the www.example.com host, in effect requesting www.example.com/samples/snippet.html.

How is the Host header manipulated?

Setting the Host header to an arbitrary value when sending an HTTP request is trivial – all the attacker needs to do is send the request manually using a free tool like telnet or cURL. The attacker’s challenge lies in delivering that request to the intended web application.

If the sender specifies a Host header that is incorrectly formed or not known to the web server, most web servers will pass the request to the first virtual host on the list. In such cases, it’s possible to send requests with arbitrary Host headers to the first virtual host but not to other virtual hosts on the same server. However, some servers may reject all requests with incorrect or unknown Host values, eliminating this avenue of manipulation.

You can also manipulate Host headers by using host override headers. The web server might be configured to accept the X-Forwarded-Host header and use its value to rewrite the original Host header value before processing. To take advantage of this, you could send requests similar to the following, where www.example.com is the legitimate host you want to replace with the malicious www.vulnweb.com:

GET /index.php HTTP/1.1
Host: www.example.com
X-Forwarded-Host: www.vulnweb.com

Yet another option for an attacker is to supply duplicate Host headers. If systems differ in how they interpret multiple Host headers in one request, a Host header injection vulnerability may result. For the following request, this could happen if the web server directs the request to the site specified in the first Host header it encounters, while the web application assumes that the host is defined by the last Host header:

GET /index.php HTTP/1.1
Host: www.example.com
Host: www.vulnweb.com

How can a manipulated Host header harm a web application?

Most web applications are designed to be deployed on any host and any domain, but sometimes they may need to know what host/domain they are deployed on. This is often required when the application needs to build an absolute URL, for example, for email functionality.

Major web applications such as CMS systems usually ask you for the hostname during initial setup and store that value in safe configuration files. However, it is also common for application developers to assume they can simply take the hostname from the Host header of HTTP requests. This violates a fundamental law of application security: never blindly trust user input or any other user-controllable data.

If your application uses the hostname from the Host header without sanitizing it, an attacker may use this to supply malicious content from a host they control. The consequences depend on how your vulnerable website uses the Host header value.

Types of Host header attacks

The following are some of the most common attacks performed using the Host header. Note that the impact of the attack depends on how the web application uses the Host header value.

• If the Host header value is used to build a URL for password reset links, password reset poisoning attacks are possible. Password reset functionality abuse is the most common use of Host header attacks.
• If the application uses the Host header to build script URLs, attackers can use malicious Host headers for web cache poisoning. This can affect any vulnerable caching mechanisms between the client and the server, including a caching proxy run by the site itself, downstream providers, content delivery networks (CDNs), and syndicators. Once poisoned, the cache then serves malicious content to anyone who requests it, allowing for very effective persistent cross-site scripting (XSS) attacks.
• If the application uses Host header values to construct SQL queries, it may be vulnerable to SQL injection via the Host header. Similarly, if it uses Host header values to construct operating system commands, it may be vulnerable to OS command injection. The same applies to other types of server-side vulnerabilities caused by the application accepting user input from the Host header without validation.

• If the web server hosts other internal applications, Host header manipulation may allow attackers to access systems and functionality only accessible from the intranet or to local users, such as administrative panels. If local user authentication is based on the hostname, this opens up yet another attack vector.
• Manipulated Host headers can also open the way for attacks such as server-side request forgery (SSRF). A typical scenario involves load-balancing system misconfigurations where the Host header is used to direct traffic to other sites on a local network. Header manipulation can then allow an attacker to specify sites that should not be accessible from the outside.

How to detect Host header vulnerabilities?

The best way to detect vulnerabilities that make Host header attacks possible depends on whether they are already known or unknown.

• If you only use commercial or open-source web applications, it may be enough to identify the exact version of the application you are using. If the identified version is known to be susceptible to Host header attacks, you can assume that your installation is vulnerable. You can identify the web app version manually or use a suitable security tool, such as a software composition analysis (SCA) solution.
• If you develop your own web applications or want the ability to potentially find previously unknown vulnerabilities that lead to Host header attacks (zero-days) in known applications, you must be able to successfully exploit the vulnerability to be certain that it exists. This requires either performing manual penetration testing with the help of security researchers or using a vulnerability scanner tool that can automatically exploit web vulnerabilities. Examples of such tools are Invicti and Acunetix by Invicti. We recommend using this method even for known vulnerabilities.

How to prevent Host header attacks?

The best way to prevent all Host header attacks is to never use Host header values anywhere in your web applications. While it is common to use the Host header to identify the application host automatically, it is more secure to specify the hostname manually.

When using a web application framework, you can use the hostname value stored by the framework. Frameworks ask you for the hostname during setup and then store that value securely in a configuration file (e.g. Joomla, Drupal), database (WordPress), environment variable (Laravel), or service registry (Kubernetes DNS).

If your application needs the value of the Host header to work properly and there is no workaround, build a whitelist of accepted host names. For example, if your web server serves 10 hosts, you should only accept these 10 hostnames as Host header values.