Host Header Injection: When the Web Server Trusts Too Much
Exploiting the web’s implicit trust in the Host header
⚠️ Ethical Note: Only test Host header vulnerabilities on systems you own or have explicit permission to test.
Advertisement
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
1
Attacker sends malicious Host header
Example:
Example:
Host: evil.com
2
Server trusts the header
Uses it to generate links, emails, or perform actions
Uses it to generate links, emails, or perform actions
3
Application behaves unexpectedly
Generates malicious content or performs unintended actions
Generates malicious content or performs unintended actions
Advertisement
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
Advertisement
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
Advertisement
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 |
Advertisement
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
Pro Tip: Use the
SERVER_NAME variable in frameworks rather than reading the Host header directly.
Advertisement
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
- Testing often misses header manipulation
- Impact can range from XSS to complete account takeover
Advertisement
Remember: The Host header is completely attacker-controlled – treat it with the same suspicion as any other user input.
