30HTTP 主机头攻击

这是一个非常重要且常见的Web安全漏洞类别，其根源在于Web应用程序**错误地信任了客户端提供的 Host 头**。

## 什么是 HTTP Host 头？

在HTTP/1.1中，Host 请求头是**强制性**的，它的出现是因为一个物理服务器（一个IP地址）可以托管多个网站（多个域名）。当浏览器请求 http://example.com 时，它会在请求中包含：

````http
GET / HTTP/1.1
Host: example.com
...
````

这样，服务器就知道客户端想要访问的是托管在服务器上的的 example.com 这个特定的网站，而不是同一个IP下的其他网站。

## 什么是 HTTP 主机头攻击？

直接将有效载荷（exp）注入 Host 头的攻击通常被称为“Host 主机头注入”攻击。

漏洞根源：盲目信任 Host 头。

**HTTP 主机头攻击的核心问题是：Web应用程序盲目地、不加验证地使用了用户提供的 Host 头值。**

攻击者可以完全控制这个host头，他们可以发送一个畸形的 Host 头，例如：

```http
GET / HTTP/1.1
Host: evil.com
...
```

或者提供多个host头：
```http
GET / HTTP/1.1
Host: example.com
Host: evil.com
...
```

如果应用程序没有验证这个host 头就直接使用，就会导致各种安全问题。

## 密码重置中毒

这是最经典、危害最大的Host头攻击场景。

**攻击流程**：

1. 攻击者在目标网站 example.com 上输入自己的邮箱，点击“忘记密码”。
2. 网站生成一个密码重置链接，格式通常为：https://{Host}/reset?token=12345。
3. **漏洞存在**：应用程序使用请求中的 Host 头来构造这个URL。
4. 攻击者使用Burp Suite等工具拦截这个请求，并将 Host 头修改为自己的域名：Host: evil-user.net。
5. 应用程序接收到这个被篡改的 Host 头，生成了重置链接：`https://evil-user.net/reset?token=12345`。
6. 这个链接被发送到攻击者的邮箱（因为邮箱是攻击者自己输入的）。
7. 攻击者点击链接，但请求发向了 evil-user.net。攻击者在自己的服务器上捕获到这个请求，从而**窃取到密码重置token**。
8. 攻击者现在可以用这个token去重置真实用户 `victim@example.com` 的密码，从而接管其账户。

## Web缓存中毒

这种攻击的影响范围更广，可以影响到所有访问被污染缓存的用户。

**攻击流程**：

1. 目标网站使用缓存服务器（如CDN、反向代理）。

2. 应用程序在响应中使用 Host 头来生成绝对URL（例如，`<script src="https://{Host}/static.js"></script>`）。

3. 攻击者发送一个恶意请求：

```http
   GET / HTTP/1.1
   Host: evil-user.net
   ```

4. 缓存服务器通常使用请求的**路径**（`/`）作为缓存键，而忽略 `Host` 头。

5. 应用程序返回响应，其中包含恶意链接：`<script src="https://evil-user.net/malicious.js"></script>`。

6. 缓存服务器将这个恶意响应存储起来，键为 `GET /`。

7. **当其他正常用户访问首页（`https://example.com/`）时，缓存服务器会直接返回这个被污染的响应，导致他们的浏览器加载并执行来自 `evil-user.net` 的恶意脚本。**

## 绕过访问控制

某些应用程序可能会根据 Host 头来实施一些简单的安全策略。

**攻击场景**：

- 应用程序只允许 `Host: example.com` 的请求访问管理功能。
- 攻击者修改 `Host` 头为 `example.com`，但请求发向的是应用程序的IP地址或另一个域名。
- 如果应用程序的验证逻辑有缺陷（例如，只是简单地进行字符串匹配），攻击者可能通过提供 `Host: example.com.admin.evil-user.net` 或 `Host: example.com` 来绕过检查，访问到管理功能。

## 服务端逻辑缺陷

应用程序在任何业务逻辑中使用 `Host` 头都可能导致问题。

**示例**：

- 根据 `Host` 头决定重定向目标。
- 在数据库查询中使用 `Host` 头作为参数。
- 在电子邮件模板中使用 `Host` 头生成链接。
- 与SSO（单点登录）系统集成时使用 `Host` 头进行回调验证。

攻击者操纵 `Host` 头可以破坏这些逻辑，导致各种意想不到的行为。

## 防护措施

防御的关键在于：**绝对不要信任用户输入的 `Host` 头**。

**1. 对开发人员的建议（应用层防御）**

**使用服务器配置的权威域名**：在应用程序的配置文件中硬编码一个或多个合法的域名（如 `ALLOWED_HOSTS = ['example.com', 'www.example.com']`）。在任何需要用到域名的地方（生成链接、重定向、邮件），都从这个配置中读取，**而不是从 HTTP 请求头中读取**。

**验证 Host 头（白名单验证）**：如果确实需要读取 `Host` 头，必须在第一时间进行严格验证。

- 定义一个允许的主机名白名单。
- 检查传入的 `Host` 头是否完全匹配白名单中的某个值。
- 如果不匹配，应直接拒绝请求，返回 `400 Bad Request` 错误。
- **绝大多数现代Web框架（如Django, Rails, Laravel）都内置了这个功能**，你只需要在配置中设置 `ALLOWED_HOSTS` 或等效选项即可。

**2. 对服务器管理员建议（基础设施层防御）**

- **配置虚拟主机**：确保Web服务器（如Nginx, Apache）正确配置了虚拟主机，默认的或“捕获所有”的虚拟主机应返回一个错误页面，而不是有效网站的内容。
- **避免使用Host头进行路由**：负载均衡器和反向代理不应仅仅依赖 `Host` 头来决定将请求转发到哪个后端服务器。