The use of HTTP Host header is to identify which component the client wants to communicate with. Nowadays web servers are configured with more than one web application using same IP address. Several misconfigurations and flaws can expose the web application to a different types of host header attacks. Before going more about host header attack, lets understand some basic term.

HOST Header

A host header must be sent in HTTP/1.1 request messages. A 400(BAD REQUEST) status code to be sent to any HTTP/1.1 request messages if there is no host header or it contain more than one header. The Host header specifies the host and port number of the server to which the request being sent.

If no port is added the default port of the service will be implied which means 80 for HTTP and 443 for HTTPS.

Host Header attack

Host header attack is a vulnerability in which attacker can manipulate the HTTP Host header and cause the web application to behave in different ways. If the web server trusts the host header implicitly and does not properly validate the host header, an attacker can inject harmful payloads to manipulate the server-side behaviour.

How to bypass or test if the application is vulnerable to Host header attack?

Testing for Host header attack is very easy. Check whether you can modify the host header and still you are able to make the request to the application.

1. Provide a random domain-Supply a random domain in host header and if in response we get 200 OK, then we can escalate the attack further.

2. Duplicate host header- Add multiple host header, if 200 OK is received you can attack further.

3. Line wrapping- Add multiple host header but make sure one host header is line wrapped and look for response.

4. Host override headers-Add host override headers like X-Forwarded-Host, X-Host, X-Forwarded-Server, X-HTTP-Host-Override Forwarded and check the responses.

What vulnerabilities can be exploited by changing the host header?

• Web-cache poisoning
• Password reset poisoning
• Redirection to attackers-controlled domain
• Perform business flaws in specific functionality
• Routing-based SSRF

Demo

For demo purpose we are using Portswigger password reset poisoning vulnerability lab:- https://portswigger.net/web-security/host-header/exploiting/password-reset-poisoning/lab-host-header-basic-password-reset-poisoning

An attacker uses password reset poisoning vulnerability to take control of a victim account. Some web application does not properly validate the host header and directly uses the host header which are in the password reset link.

Step 1: Go to password reset page and enter a valid name and intercept the request using proxy.

Step 2: Change the host header to attacker domain where all the requests are logging in.

Step 3: After passing the request we got a 200 OK request.

Step 4: Now victim will get a mail to reset the password and he unknowingly click the link.

Step 5: When victim clicks the link its all get logged in attacker’s domain logs. If we check the logs, we can see a request with password reset token.

Step 6: To reset the password of victim account, first generate a legit user password reset link and intercept that request.

Step 7: In the intercepted request replace the token value from legit users to victims account password reset token.

Step 8: After forwarding the request, attacker was able to change the password of victim account.

Remediation

• Validate and sanitize the user supplied inputs properly.
• Whitelist all the trusted domains.
• Don’t support host override headers.