Host Header Injection (HHI)
Last updated
Last updated
📚 What is HHI ?
🤔 Why HHI Happen ?
💥 Exploitation
⚔ Impact
🔎 How To Find
⚙ Remediation
🛠 Tools
📕 Referance
🔬 Labs
A web server commonly hosts several web applications on the same IP address, referring to each application via the virtual host. In an incoming HTTP request, web servers often dispatch the request to the target virtual host based on the value supplied in the Host header, Without proper validation of the header value.
if you want to visit login page in https://example.com/login The Host Header in Request will be like that:
One possible scenario is when a single web server hosts multiple websites or applications. This could be multiple websites with a single owner, but it is also possible for websites with different owners to be hosted on a single, shared platform. This is less common than it used to be, but still occurs with some cloud-based SaaS solutions.
In either case, although each of these distinct websites will have a different domain name, they all share a common IP address with the server. Websites hosted in this way on a single server are known as “virtual hosts”.
To a normal user accessing the website, a virtual host is often indistinguishable from a website being hosted on its own dedicated server.
We can even take this a step further and try to identify all sites that are hosted on the target web server by performing virtual host enumeration. How to enumerate virtual hosts? We could use tools such as these:
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.
Initial testing is as simple as supplying another domain (i.e. attacker.com) into the Host header field. It is how the web server processes the header value that dictates the impact. The attack is valid when the web server processes the input to send the request to an attacker-controlled host that resides at the supplied domain, and not to an internal virtual host that resides on the web server.
In the simplest case, this may cause a 302 redirect to the supplied domain.
Alternatively, the web server may send the request to the first virtual host on the list.
the attacker can supply invalid input to cause the webserver to:
Dispatch requests to the first virtual host on the list.
Perform a redirect to an attacker-controlled domain.
Perform web cache poisoning.
Manipulate password reset functionality.
Allow access to virtual hosts that were not intended to be externally accessible lead to information disclosure
Business logic flaws in specific functionality
Exploiting classic server-side vulnerabilities
Assess if the Host header is being parsed dynamically in the application. Bypass security controls that rely on the header.
X-Forwarded-Host Header Bypass
In the event that Host header injection is mitigated by checking for invalid input injected via the Host header, you can supply the value to the X-Forwarded-Host header.
And there are some another Headers to bypass
Others
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 validate the Host header.
use a whitelist of allowed hostnames.
Don’t support Host override headers.
Host-Header-Attack-Test: A simple code for detects Host header vulnerability
xforwardy: Host Header Injection Scanner
BHHIT-v1.0: BHHIT is a automated Host-Header-Injection attack detector.
Portswigger Password Reset Poisoning
OWASP Broken Web Applications Project Install this Machine and will have a lot of Labs like DVWA, BWAPP and Webgoat etc
