Host Header Injection
What is Host Header?
The HTTP Host represents the domain name of the server. It may also represent the Transmission Control Protocol (TCP) port number which the server uses. Defining the port number is optional, the default value is considered. For example, “80” is assigned as the port number for an HTTP URL when there is no port number specified. The HTTP Host header is a request type header. The host header field must be sent in all HTTP/1.1 request messages. If a request message does not have any header field or more than one header field, a 400 Bad Request is sent.
Syntax :
Host: <host>:<port>
Directives: The HTTP header Host accepts two directives mentioned above and described below:
<host>: This directive represents the domain name of the server.
<port>: This directive is an optional one. It represents the TCP port number in which the server is working.
Examples:
· Host for GeeksforGeeks cdn page.
Host: www.cdn.geeksforgeeks.org
· Host for GeeksforGeeks home page.
Host: www.geeksforgeeks.org
What is Host Header Injection?
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.com
Many 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.
What is the impact of Host Header Injection?
Tampering of Host header can lead to the following attacks:
1) Web Cache Poisoning-Manipulating caching systems into storing a page generated with a malicious Host and serving it to others.
2) Password Reset Poisoning-Exploiting password reset emails and tricking them to deliver poisoned content directly to the target.
3) Cross Site Scripting - XSS can be performed, if the value of Host header is used for writing links without HTML-encoding. For example Joomla used to write Host header to every page without HTML Encoding like this: <link href=”http://_SERVER['HOST']”> which led to cross site scripting.
4) Access to internal hosts-To access internal hosts.
5.) It can also lead to Phishing Attacks.
How do you prevent it?
To prevent HTTP Host header attacks, the simplest approach is to avoid using the Host header altogether in server-side code. Double-check whether each URL really needs to be absolute. You will often find that you can just use a relative URL instead. This simple change can help you prevent web cache poisoning vulnerabilities in particular.
Other ways to prevent HTTP Host header attacks include:
Protect absolute URLs
When you have to use absolute URLs, you should require the current domain to be manually specified in a configuration file and refer to this value instead of the Host header. This approach would eliminate the threat of password reset poisoning, for example.
Validate the Host header
If you must use the Host header, make sure you validate it properly. This should involve checking it against a whitelist of permitted domains and rejecting or redirecting any requests for unrecognized hosts. You should consult the documentation of your framework for guidance on how to do this. For example, the Django framework provides the ALLOWED_HOSTS option in the settings file. This approach will reduce your exposure to Host header injection attacks.
Don't support Host override headers
It is also important to check that you do not support additional headers that may be used to construct these attacks, in particular X-Forwarded-Host. Remember that these may be supported by default.
Whitelist permitted domains
To prevent routing-based attacks on internal infrastructure, you should configure your load balancer or any reverse proxies to forward requests only to a whitelist of permitted domains.
Be careful with internal-only virtual hosts
When using virtual hosting, you should avoid hosting internal-only websites and applications on the same server as public-facing content. Otherwise, attackers may be able to access internal domains via Host header manipulation.
Reference: