Host Header Injection (HHI)
A Web server handles the Host header value to dispatch the request to the destination domain. An attacker can manipulate this Host header with some fake Domains to steal sensitive information.
Contents:
- Introduction
- Host Header Injection
- Why Host Header Attack Happens?
- Risk of Host Header Attack
- How Attackers Utilize Host Header Attack?
- Phases of Host Header Issues
- Web Cache Poisoning with Single Host Header
- Web Poisoning with Multiple Host Headers
- X-Forwarded Host Header
- Password Reset Poisoning
- Impacts of Host Header Issues
- Tools to find Host Header Vulnerability
- How to Host Header Attack
- Conclusion
Introduction
Web servers are configured in such a way, to hosts several websites or web applications on the same IP address. That’s why the Host Header Injection occurs. The Host Header determines which site or web application should process an approaching HTTP request. The web server utilizes the Host Header parameter value to dispatch the request to the predetermined site or web application. Each web application hosted on the same IP address is commonly referred to as a virtual host.
Here we are going to deal with Host Header Injection, its risk, forms, and impacts and how to mitigate it.
Host Header Injection
An attacker can manually divert the code to produce their desired output, simply by editing the host header value. Most probably web servers are configured to pass the unknown host header to the first virtual host in the virtual host list without proper recognition. Hence, it is possible to send the HTTP requests with arbitrary host headers to the first virtual host.
In that case, if we specify an invalid Host Name the web server processes it and passes the invalid host header to the first virtual host in the list.
Thus, an attacker can modify the host name by giving a fake web page or vulnerable website and deliver it to the user.
Example:
The result will redirect the user to the attacker’s (fake) website by simply modifying the host header value.
Why Host Header Attack Happens?
It is an injection type of attack that is done on the HTTP headers.
- HTTP headers are dynamically generated based on the input of the user. User inputs can be edited, or spoofed by attackers. It is accessible by everyone.
- If websites fail to correctly validate or verify the HTTP Host headers.
Risk of Host Header Injection Attack
Most probably, many websites use the values provided in the user input field and use it afterwards without any improper input validation. Commonly, this will not have that much impact on the application. But in some cases, if the application accepts the host header, the risk lays there. There may occur:
- URL Redirection issues.
- Username and password credentials may get stolen.
- Password Reset Poisoning.
- Session Hijacking Attack.
- Financial loss may occur.
How Attackers Utilize Host Header Attack
The exploitation is based on the logic of the web application. If the application does not use the user’s input value, then there is no risk. But, the host header attack is considered as a serious issue at the time of resetting our password. When we are resetting our forgotten password, or when we change our password for enabling our privacy, the web application generates a link dynamically. There it uses the host header provided in the request. In this scenario, the hacker uses this header for his/her evil cause. The hackers use some social engineering and phishing attacks for getting the link. So, the developers should realise the consequences of host header attack.
Phases of Host Header Injection
Web Cache Poisoning With Single Host Header
Web cache poisoning is a kind of technique used by a hacker, to manipulate a web cache that serves a poisoned content for those who requests that webpage. For this attack, the hacker needs to poison a caching proxy that is being run by the website itself, content delivery networks (CND’s), or other caching mechanisms that are carried out between the client and the server. In this scenario where caching is enabled, a hacker will potentially embed a remote URL as the base URL for any website. This causes other users, who request the site to get redirected unknowingly. Thus, if an application fails to prevent the user from using the X-Forwarded-Host header, it will effectively override the Host header. The cache will serve the poisoned content to everyone who requested the webpage, without the knowledge of the victim.
Example:
Web Poisoning With Multiple Host Headers
It is one form of web cache poisoning attack. It’s similar to that of web cache poisoning using the single header. The only difference in this type is that, it uses multiple headers more than once to the users, whom request the website. By tampering with the header, it is possible. The web cache will deliver the wrong content to the user without their knowledge.
Example:
GET / HTTP/1.1
Host: www.example.com (Actual URL)
Host: www.evil.com(Injected Fake URL)
X-Forwarded Host Header
Host header injection is mitigated by preventing the tampering of Host header. It means if any request is made with tampered host header, the application responds with an error message like “404 Not Found”. 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:
Password Reset Poisoning
The significant impact of Host header attack lies in the password resetting functionality. The most common scenario of this attack is that the hacker generates a secret token, and then sends a mail that has a link containing the mysterious symbol of the hacker. The hacker then urges the user to make use of his link and also requests a password reset link that redirects the user to him. In this case, if the web application makes use of this host header value when composing with the reset link, and when the user clicks the poisoned reset link in the mail, the user will become a victim to the hacker. The attacker will obtain the password reset token and make use of his password for his destructive purposes.
Example:
Impact of Host Header Issues
- A hacker can modify the legitimate host header with a wrong host in the request, and it poisons the cache of the web application server as well the proxy. It has nothing to do with the browser. When the authorised user tries to access the host, the cache of the web server is poisoned with the hacker’s domain that redirects the user to the domain of the hacker.
- If the host headers are used for writing links without a proper HTML encoding, there may be a possibility for Cross-site scripting.
- Access to the internal host.
- HTML INJECTION can also be done.
Tools to find Host Header Vulnerability
An open-source Python based automated scanner that detects Host-Header-Injection vulnerability.
XForwardy is a Host Header Injection scanning tool which can detect misconfigurations, where Host Header Injections are potentially possible.
A simple code for detects Host header attack.
How To Mitigate Host Header Attack
- Validate and Sanitize the user supplied inputs properly.
- Proper validation of the request, whether it came from the original target host or not.
- Mitigate the Host header attack in Apache and Nginx by creating a dummy virtual host that catches all requests from unrecognised Host headers.
- Whitelist all the trusted domains at the initial phase of the web application.
- Respective mapping of the domains that are received in the host header of each HTTP request with itself.
- Use secure server configuration.
Conclusion
Many application developers did not realize that the HTTP host header is accessible and controllable by all users. In an application security perspective, the input given by the user is always deceivable, and it is unsafe to trust. So, a web developer should consider host header issues as a serious ongoing threat, which must be inspected deeply. Moreover, we must implement the required mitigation measures to safeguard ourselves.