内容摘要：一个请求发到服务器，Host 头写着 `evil.com`，服务器照样把页面吐了出来——这就是 Host 头注入漏洞最朴素的样子。低危，扫描器报出来的时候往往只给一行黄字，很多人扫一眼就关掉了。但它的

一个请求发到服务器，头注Host 头写着 `evil.com`，入漏服务器照样把页面吐了出来——这就是洞低 Host 头注入漏洞最朴素的样子。低危，头注扫描器报出来的入漏时候往往只给一行黄字，很多人扫一眼就关掉了。洞低但它的头注价值不在自身危害等级，而在于它经常是入漏其他攻击链的第一块拼图。

HTTP/1.1 规定 Host 头是洞低必填的。它的头注本意很简单：让同一台 IP 上的多个网站知道用户想访问哪一个。问题出在，入漏不少应用直接拿这个值去干活——生成链接、洞低拼接重定向地址、头注写日志、入漏发邮件里的洞低 URL，甚至塞进缓存键。你控制了这个头，就等于控制了一部分应用的输入。

它到底能干什么

最直接的场景是密码重置投毒。用户点“忘记密码”，应用生成一封邮件，里面写着“点击链接重置：https://Host头的内容/reset?token=abc”。如果 Host 被改成攻击者的域名，这封邮件就会把重置令牌送到攻击者服务器上。低危？对，单独看这个漏洞是低危，但配合密码重置流程，它直接变成账户接管。

另一个常见落点是缓存投毒。CDN 或反向代理把 Host 头纳入缓存键的组成部分，或者更糟——不纳入但应用用它生成页面内容。攻击者发一个 Host 为 `attacker.com` 的请求，让缓存存下包含 `attacker.com` 链接的页面，后续正常用户拿到的是被污染的缓存。这种利用链在实战中出过不少案例，赏金也不低。

还有虚拟主机路由绕过。有些架构里，前端代理根据 Host 决定把请求转发给哪个后端。如果代理配置不严，Host 写成内网服务名，就能摸到本来不该暴露的接口。这类问题在云环境里尤其常见，Kubernetes Ingress、Nginx 虚拟主机配置写错一行，边界就模糊了。

为什么总被标成低危

因为扫描器只能验证“服务器接受了任意 Host 并返回了 200”。它没法判断这个 Host 值后来被用在哪里。一个应用可能接收了任意 Host，但只拿它做日志记录，那确实没什么危害。可同样的接收行为，换一个应用就是密码重置投毒。评级系统给的是通用分，真实风险得看上下文。

我自己的习惯是，看到 Host 头注入的告警，先不急着关。去翻这个站有没有密码重置、邀请链接、邮件模板、重定向接口。有其中一个，就手动构造请求验证。没有的话，再看它前面有没有 CDN 或缓存层。都没有，再降级处理。

怎么修才不糊弄

最省事的做法是配一个允许的 Host 白名单，Nginx 里 `server_name` 写死，或者应用层加校验。但白名单要维护，多域名、多环境容易漏。另一种思路是根本不信任 Host 头，生成绝对 URL 时从配置里读域名，而不是从请求里取。这个改动小，但需要开发愿意动代码。

反向代理层也可以兜底。比如在代理上重写 Host 为固定值再转发给后端，后端就永远看不到恶意 Host。代价是后端拿不到原始 Host，如果业务确实需要区分域名，就得用其他头传递，比如 `X-Forwarded-Host`，但那个头同样不可信，还是得校验。

修这个漏洞不难，难的是意识到它值得修。低危标签容易让人跳过，而跳过的那一下，可能就漏掉了后面那条完整的攻击路径。