The HTTP Host header is a mandatory request header as of HTTP/1.1 and it tells the server which domain the client (like a browser) is trying to access.
Example:
When a user visits the following URL:
https://www.testsite.in/mobile-phones/b?ie=UTF8&node=1389401031
The browser sends this request
GET /mobile-phones/b?ie=UTF8&node=1389401031 HTTP/1.1 Host: www.testsite.in
Sometimes, the request passes through a proxy, CDN, or load balancer and these systems can change the Host header before it reaches the back-end server which can lead to security issues if the app trusts the modified Host header without validation.
Why the Host Header Matters:
The Host header tells the server which website or application the client wants and without it, the server wouldn't know where to route the request — especially if it hosts multiple apps.
Earlier there was no confusion as we have one IP address = one website. But now multiple apps are being hosted on a single IP address for efficiency and there is shortage of IPv4 addresses, so sharing IPs is necessary.
When multiple websites share the same IP address, the HTTP Host header becomes essential for routing requests correctly. Two key scenarios where this occurs are:
i. Virtual Hosting: A single web server hosts multiple websites (virtual hosts), each with a different domain name. Though they share one IP, users see them as completely separate websites. This is common with some SaaS platforms or shared hosting environments.
ii. Routing via Intermediary: Websites may live on separate back-end servers, but all traffic flows through an intermediary like a reverse proxy, load balancer, or CDN. The Host header tells the intermediary which back-end server to route each request to.
In both setups, proper handling of the Host header is critical — not just for functionality, but also to prevent attacks like Host header injection.
What Is a Host Header Attack?
An HTTP Host header attack targets web applications that trust and use the Host header value without proper validation or sanitization.
Attackers can manipulate this header to: a. Bypass access controls b. Perform password reset poisoning c. Trigger SSRF (Server-Side Request Forgery) d. Exploit web cache poisoning e. Phish users through crafted URLs
How to Detect Host Header Vulnerabilities
Here are practical methods for testing if an app is vulnerable to Host Header attacks:
- Supply an arbitrary Host header: Change the Host header in the request to something like abc.com or testsite12.com using Burp Suite and if the app still works or reflects this fake host, it may be vulnerable.
- Check for flawed validation: Check if the server blocks or accepts our fake Host header. Some apps have weak checks — try bypassing them using tricks like adding ports (www.testsite.in:not-vulnerable) or special characters.
- Send ambiguous requests: Sometimes different parts of an app handle the Host header differently. You can try confusing them by crafting ambiguous requests:
3.1 Add Duplicate Host Headers: Add two Host headers in the same request
Host: www.testsite.com Host: www.testsite123.in
3.2 Add Line Wrapping: Indent headers with a space
GET /mobile-phones/b?ie=UTF8&node=1389401031 HTTP/1.1 Host: www. tests.com Host: www.testsite.in
4. Inject Host override headers: Even if we can't directly change the Host header, some servers and proxies accept alternative headers that can override it. These are known as host override headers.
Few of the common Host Override Headers: X-Host, X-Forwarded-Server, X-HTTP-Host-Override, Forwarded
GET /mobile-phones/b?ie=UTF8&node=1389401031 HTTP/1.1 Host: www.testsite.in X-Forwarded-Host: not-vulnerable
Prevention Techniques:
1. Use Relative URLs Whenever Possible: Avoid using full (absolute) URLs on the server side unless necessary. Stick with relative URLs to minimize risks like web cache poisoning.
2. Protect Absolute URLs: If you must use absolute URLs (e.g., in password reset emails), don't trust the Host header. Instead, store your domain name securely in a configuration file and always reference that.
3. Disable Host Override Headers: Ensure your server doesn't trust headers like X-Forwarded-Host, unless required. These headers are often abused in attacks.
4. Whitelist Back-end Domains: Configure reverse proxies or load balancers to forward requests only to known, safe back-end servers.
5. Keep Internal Apps Separate: Avoid hosting internal apps on the same server as public websites. Host header tricks can expose internal services if they're not isolated.
Reference:
HTTP Host header: HTTP Host header attacks | Web Security Academy