做网站运维或者安全测试的朋友，经常会在漏洞报告里看到一个词：主机头攻击，英文叫 Host Header Injection。很多人第一次听到会一头雾水，主机头不就是一个 HTTP 请求里的 Host 字段吗，怎么还能被攻击？其实这个看似不起眼的字段，一旦服务端处理不当，就可能引发密码重置劫持、缓存投毒、SSRF 等一系列严重问题。这篇文章就用大白话把主机头攻击讲清楚，包括它的原理、常见利用方式和防护措施。
什么是主机头
HTTP 请求头里有一个 Host 字段，用来告诉服务器用户想访问哪个站点。尤其是在虚拟主机环境下，一台服务器上可能跑着几十个网站，IP 是同一个，服务器就是靠 Host 字段来判断这个请求该转发给哪个网站处理。正常情况下，Host 的值来自浏览器地址栏的域名，用户自己改不了。但问题在于，任何人都可以用工具直接构造 HTTP 请求，把 Host 字段随便填写，服务器如果不做校验，就直接拿来用了，这就是主机头攻击的根源。
主机头攻击的常见利用方式
第一种是密码重置投毒，这也是最常见、危害最大的一种。很多网站生成密码重置链接时，直接从请求头里取 Host 来拼接链接，比如生成一个 http://Host/reset?token=xxx 这样的地址发给用户邮箱。攻击者只需要在发起重置请求时，把 Host 改成自己的恶意域名，服务器就会生成一个带恶意域名的重置链接发给受害者。受害者一点击，重置令牌就落到攻击者手里，账号直接被接管。
第二种是 Web 缓存投毒。如果网站前面有 CDN 或者反向代理缓存，攻击者构造一个带恶意 Host 的请求，服务器生成页面时把这个恶意值嵌入进去，缓存服务器又恰好把这份被污染的页面缓存下来，那么后续所有访问同一资源的用户都会看到被篡改的内容，可能包含恶意脚本，造成大面积 XSS 攻击。
第三种是绕过访问控制。有些系统会根据 Host 来判断请求是否合法，比如只允许管理后台通过特定域名访问。如果判断逻辑写得有漏洞，攻击者伪造 Host 就可能绕过限制，直接访问内部接口。另外一些应用还会把 Host 传递给内部服务做请求转发，伪造的 Host 可能导致 SSRF，让服务器去请求攻击者指定的内网或外部地址。
第四种是影响链接生成。除了密码重置，很多邮件通知、二维码、分享链接都是从 Host 拼出来的，被篡改后同样可以把用户引导到钓鱼页面。
主机头攻击的检测思路
想测试自己网站是否存在这个漏洞，可以用 Burp Suite 或者 curl 直接改 Host 字段发请求，然后观察服务器响应。比如把 Host 改成一个不存在的域名，看页面里有没有出现这个域名；向自己的邮箱发送重置密码请求，检查收到的链接是不是用的你伪造的域名；还可以试试 X-Forwarded-Host 这个头，有些应用会优先取代理传递的头来构建链接，同样存在被注入的可能。如果发现页面内容、跳转地址或者生成的链接跟着你伪造的 Host 变化，基本就可以确认存在漏洞。
如何有效防御主机头攻击
防御的核心思路就一句话：不要信任用户可控的 Host。具体做法有以下几点。
第一，在 Web 服务器层面配置白名单。Nginx 和 Apache 都支持配置默认虚拟主机，把没有匹配到合法域名的请求全部拒绝，返回 444 或者 403。比如 Nginx 里设置一个 default_server，对不认识的 Host 直接丢弃，这是最有效的一道防线。
第二，应用代码里不要从请求头动态获取域名。把网站的完整域名写进配置文件，生成密码重置链接、邮件通知时直接用配置里的固定值，这样即使攻击者改了 Host 也没用。
第三，谨慎使用 X-Forwarded-Host 等代理头。只有在确认前面有可信的代理服务器时才读取这些头，并且要在代理层把用户伪造的头覆盖掉，确保传到应用里的值是代理自己填的。
第四，定期做安全测试。上线前和日常维护中，主动用改 Host 的方式做一轮测试，确认各类动态链接不受影响。也可以在 WAF 里配置规则，校验 Host 是否在合法域名列表内，不合法直接拦截。
总结
主机头攻击本质上是一个信任问题：服务器把本该由用户浏览器提供、不可控的请求头当成了可信数据来用。只要养成习惯，域名一律走配置文件，服务器层做好 Host 白名单校验，这个漏洞就能彻底堵死。安全无小事，一个 HTTP 头引发的账号接管事故并不少见，希望这篇文章能帮你把主机头攻击的防护真正落地。