内容摘要：2019年，某云服务商的安全团队做了一次扫描，全球Top 10000的网站里，超过15%的站点对Host头完全没有校验。这意味着什么？攻击者只要改一个HTTP请求头，就能让服务器乖乖交出不该给的东西。

2019年，头攻某云服务商的击漏安全团队做了一次扫描，全球Top 10000的头攻网站里，超过15%的击漏站点对Host头完全没有校验。这意味着什么？头攻攻击者只要改一个HTTP请求头，就能让服务器乖乖交出不该给的击漏东西。

Host头是头攻HTTP/1.1协议里的一个字段，用来告诉服务器"我要访问的击漏是哪个域名"。一台服务器上可能跑着几十个网站，头攻全靠这个字段来区分。击漏问题就出在这里——很多后端程序直接信任了这个值，头攻拿去做逻辑判断、击漏拼接URL、头攻甚至写进数据库。击漏

密码重置链接被劫持

一个真实场景：某网站找回密码功能，头攻用户提交邮箱后，系统生成一条重置链接发到邮箱里。链接的域名部分怎么来的？直接从请求的Host头取。攻击者把自己的Host改成evil.com，触发受害者的邮箱收到一封重置邮件，链接指向http://evil.com/reset?token=xxxx。受害者一点，token就泄露了。

这个漏洞的本质是：服务器把用户可控的输入当成了可信的配置。Host头是客户端发来的，任何人都能改，它跟URL路径、Cookie一样属于不可信输入。

缓存污染才是大杀器

密码重置劫持只是开胃菜。Host头攻击配合Web缓存，能造成更大面积的伤害。CDN和反向代理通常按URL做缓存，但有些实现会把Host也纳入缓存键，有些不纳入。如果缓存键不包含Host，攻击者发一个请求，Host设为attacker.com，页面里所有相对URL都变成指向attacker.com。这个响应被缓存后，后续正常用户访问同一路径，拿到的就是被污染的页面。所有链接、表单提交地址全指向攻击者的服务器。

这种攻击不需要接触目标服务器，只需要在缓存过期前发一个精心构造的请求。Cloudflare、Akamai都出过类似的案例报告。

虚拟主机路由绕过

内部网络里，Host头还能用来绕过访问控制。假设一台Nginx反代后面挂着两个后端：public.example.com对外，admin.internal只允许内网访问。Nginx按Host做路由。如果攻击者从外网发请求，Host设为admin.internal，而Nginx没有额外做来源IP校验，请求就被转发到了管理后台。这类配置错误在微服务架构里特别常见，网关层觉得"我按Host转发就行了"，安全边界形同虚设。

怎么防

最直接的办法：服务端不要用Host头做任何安全决策。需要生成绝对URL时，从配置文件或环境变量里读固定域名，别从请求里取。Nginx可以配一个默认server块，Host不匹配任何已知域名就直接返回444。Apache有UseCanonicalName On，强制用配置里的ServerName。

如果业务上确实需要多域名支持，维护一个白名单，请求进来先查表，不在表里的直接拒绝。应用层框架大多有对应的配置项，Django的ALLOWED_HOSTS、Rails的config.hosts，设好就行。别偷懒写*。

缓存层要确保缓存键包含Host，或者干脆在回源请求里重写Host为固定值。CDN厂商的控制面板里通常有这个选项，默认不一定开。

我自己的习惯是，拿到一台新服务器，先发一个curl -H "Host: random.test" http://ip/，看看返回什么。如果返回了正常页面而不是400或444，那就有问题。这个检查花不了十秒钟，但能挡掉一大类低级错误。

Host头攻击的根因不是协议缺陷，是开发者的假设出了问题。默认信任客户端输入，迟早要还债。