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 头来决定将请求转发到哪个后端服务器。