Exploiting HTTP Host Header: From Password Reset Poisoning to SSRF
This article explains the purpose of the HTTP Host header, how Host header attacks work, methods to discover and exploit them—including password‑reset poisoning, cache poisoning, access‑control bypass, and SSRF—and provides practical mitigation techniques for developers and security teams.
1. HTTP Host Header Attack
Since HTTP/1.1 the Host header is mandatory and specifies the domain the client wants to reach. Example request:
GET /web-security HTTP/1.1
Host: example.netIf a proxy forwards the request, the Host value may be altered before reaching the backend, leading to a Host header attack.
2. Role of the HTTP Host Header
The Host header helps the backend identify which application should handle the request. When missing or malformed, it can cause problems. Historically this was less of an issue because each IP served a single domain, but with virtual hosting and shared IPs it became critical.
Virtual hosting
Proxy‑routed traffic (load balancers, CDNs)
The Host header works like the apartment number on a letter, directing it to the correct recipient.
3. What Is an HTTP Host Header Attack
Some applications trust the Host header without validation. An attacker can inject a malicious Host value to manipulate server behavior, such as generating URLs for password‑reset emails.
<a href="https://_SERVER['HOST']/support">Contact Support</a>Because the Host header is user‑controllable, it can be combined with other vulnerabilities like cache poisoning, logic flaws, SSRF, or SQL injection.
4. How to Discover HTTP Host Header Attacks
First, check whether the server validates the Host header. Then modify the Host value and observe the response. If the server reflects the modified value, it is vulnerable. Common techniques include:
Modify Host Value
Change the Host header and see if the payload appears in the response.
Add Duplicate Host Headers
GET /example HTTP/1.1
Host: vulnerable-website.com
Host: attack-stuffOne header may be used for routing, the other for payload delivery.
Use Absolute‑URL Requests
GET https://vulnerable-website.com/ HTTP/1.1
Host: attack-stuffAdd Indentation or Newlines
GET /example HTTP/1.1
Host: attack-stuff
Host: vulnerable-website.comInject via Similar Fields
GET /example HTTP/1.1
Host: vulnerable-website.com
X-Forwarded-Host: attack-stuffOther fields such as X‑Host, X‑Forwarded‑Server, X‑HTTP‑Host‑Override, Forwarded can also be abused.
Ignore Port, Validate Only Domain
GET /example HTTP/1.1
Host: vulnerable-website.com:attack-stuffIf the server ignores the port, the payload can be placed after the colon.
5. HTTP Host Header Attack Vulnerability Examples
5.1 Password‑Reset Poisoning
When a password‑reset link is generated using the Host header, an attacker can change the Host to a domain they control, stealing the reset token.
https://normal-website.com/reset?token=0a1b2c3d4e5f6g7h8i9jBy modifying the Host to evil-user.net, the victim receives a link pointing to the attacker’s site, allowing token capture and password change.
5.2 Host Header + Cache Poisoning
If the site caches resources based on the Host header, an attacker can poison the cache with malicious JavaScript (e.g., alert(document.cookie);) that will be served to other users.
5.3 Host Header Bypass of Access Control
Changing the Host to an internal address can bypass IP‑based access restrictions, granting access to admin pages.
5.4 Host Header + SSRF
When the server uses the Host header to make internal requests, an attacker can direct those requests to internal services (e.g., 192.168.0.240) and retrieve sensitive data.
GET http://internal‑service/ HTTP/1.1
Host: 192.168.0.2406. Mitigations for HTTP Host Header Attacks
Prefer relative URLs instead of relying on the Host header.
6.1 Properly Configure Absolute URLs
When absolute URLs are required, store the domain in configuration and do not derive it from the Host header.
6.2 Whitelist Validation
Validate the Host header against an allow‑list of known domains and reject or redirect unknown hosts.
6.3 Disable Header Overwrites
Ensure fields like X‑Forwarded‑Host are not trusted unless explicitly needed.
6.4 Separate Internal and Public Hosts
Do not host internal services on the same server as public applications to prevent Host header manipulation from reaching internal resources.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Programmer DD
A tinkering programmer and author of "Spring Cloud Microservices in Action"
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
