Host Header Hunting: Techniques, Vulnerabilities, and Exploits

Host header attacks are a common web vulnerability that can lead to serious security risks like cross-site scripting (XSS), password reset hijacking, and even web cache poisoning. This blog will discuss various methods to discover host header injection points and demonstrate how attackers can exploit them.

Understanding Host Header Injection

Host header injection occurs when a web application relies on the Host header from the HTTP request without proper validation. This can allow attackers to modify the header, redirect requests, or cause other security issues.

Common HTTP Status Codes to Watch Out For

When testing for host header injection, certain status codes can provide valuable insights:

• 200 OK: The request was successful.
• 201 Created: The request has resulted in a new resource being created.
• 202 Accepted: The request has been accepted but has yet to be processed.
• 203 Non-Authoritative Information: Information returned by a proxy but not from the origin server.
• 204 No Content: The server successfully processed the request, but there is no content to send back.

Similarly, redirection status codes can help identify unusual behaviors:

• 300 Multiple Choices
• 301 Moved Permanently
• 302 Found
• 303 See Other
• 304 Not Modified

These status codes could indicate improper header handling, making them useful for detecting host header injection vulnerabilities.

Method 1: Changing the Real Host to an External Domain

In this method, you alter the Host header from its real value to another domain such as bing.com. This is a simple and effective way to test how the application processes the Host header. If the server accepts this modified header and processes the request, it strongly indicates that the application is vulnerable to host header injection.

Example:

Original request:

Host: realweb.com

Modify to:

Host: bing.com

If the server processes this without any validation, you have a potential host header injection vulnerability.
Method 2: Manipulating X-Forwarded-Host
The second method involves altering both the Host and X-Forwarded-Host headers. 
Many web applications trust the X-Forwarded-Host header, which can be used to bypass the validation of the Host header.

Example:
Host: realweb.com
X-Forwarded-Host: bing.com

Here, the X-Forwarded-Host is set to bing.com, while the Host remains unchanged. 
This could be used to manipulate how the server interprets the origin of the request.

Method 3: Inverting Host and X-Forwarded-Host
In the third method, we invert the Host and X-Forwarded-Host headers to see how the application behaves when these two headers conflict.
Example:
Host: realweb.com
X-Forwarded-Host: bing.com

In this case, the Host header is set to the actual domain, but X-Forwarded-Host is manipulated. If the application trusts the X-Forwarded-Host header, 
it may lead to security issues such as redirects or content injection.