Host Header Injection: When the Web Server Trusts Too Much
Exploiting the web’s implicit trust in the Host header
Thank you for reading this post, don't forget to subscribe!What is Host Header Injection?
Host Header Injection occurs when a web application improperly uses the HTTP Host header without proper validation or sanitization. This trust can lead to various attacks including:
- Web cache poisoning
- Password reset poisoning
- SSRF (Server-Side Request Forgery)
- Cross-site scripting (XSS)
- Business logic bypasses
Example:
Host: evil.com
Uses it to generate links, emails, or perform actions
Generates malicious content or performs unintended actions
Why This Vulnerability Exists
| Root Cause | Example | Impact |
|---|---|---|
| Implicit trust in headers | Using Host header for password reset links | Account takeover |
| Lack of validation | Accepting arbitrary Host values | Cache poisoning |
| Improper canonicalization | Treating example.com and example.com.malicious.com as same |
Phishing attacks |
Exploitation Techniques
Basic Host Header Manipulation
GET / HTTP/1.1 Host: evil.com
Common Attack Vectors
- Password Reset Poisoning: Injecting malicious host in reset emails
- Cache Poisoning: Storing malicious responses in CDN caches
- SSRF Attacks: Using Host header to reach internal services
- XSS via Host Header: When Host value is reflected unsanitized
- Virtual Host Brute Forcing: Discovering hidden internal domains
Advanced Exploitation
1. Password Reset Poisoning
POST /password-reset HTTP/1.1 Host: evil.com ... email=victim@real.com
2. Web Cache Poisoning
GET / HTTP/1.1 Host: evil.com X-Forwarded-Host: attacker.com
3. SSRF via Host Header
GET /internal-resource HTTP/1.1 Host: 169.254.169.254
Testing Methodology
| Test | Payload | Expected Result |
|---|---|---|
| Basic override | Host: evil.com |
Site uses evil.com in links/redirects |
| Duplicate headers | Two Host headers | See which one the app processes |
| Absolute URLs | GET http://evil.com/ HTTP/1.1 |
Server processes evil.com as host |
| Port manipulation | Host: evil.com:80 |
Check if port is validated |
Defensive Strategies
1. Secure Server Configuration
# Nginx configuration
server {
listen 80;
server_name example.com;
if ($host != "example.com") {
return 444;
}
...
}
2. Application-Level Protections
- Whitelist acceptable domain names
- Never use Host header for sensitive operations
- Use relative URLs instead of host-based absolute URLs
- Validate and sanitize all header values
- Implement proper CORS policies
3. Security Headers
Content-Security-Policy: default-src 'self' X-Frame-Options: DENY Referrer-Policy: strict-origin-when-cross-origin
SERVER_NAME variable in frameworks rather than reading the Host header directly.
Real-World Examples
Case 1: Password Reset Hijacking
A popular SaaS platform used the Host header to generate password reset links, allowing attackers to steal tokens by setting Host: attacker.com.
Case 2: Cache Poisoning Attack
Major news site cached responses with malicious Host headers, serving JavaScript from attacker domains to all visitors.
Case 3: Internal Service Access
E-commerce platform allowed Host header to reach internal metadata services (like AWS metadata service).
Conclusion
Host Header Injection remains a serious threat because many frameworks implicitly trust headers, and testing often misses header manipulation. The impact can range from XSS to complete account takeover.
Further Resources
