一个晴朗的头攻下午，我对着公司内部的击漏一个测试站点随手改了改Host字段，把`example.com`换成了`evil.com`。洞验服务器居然乖乖地把我带到了一个完全不同的头攻页面——一个密码重置链接。这个链接里的击漏域名，正是洞验我伪造的那个。如果这发生在生产环境，头攻攻击者只需要诱导用户点击一封精心构造的击漏邮件，就能拿到受害者的洞验重置令牌，进而接管账号。头攻

这就是击漏Host头攻击，一种常被忽视但危害直接的洞验漏洞。它的头攻根源在于，很多Web应用在生成绝对URL时，击漏盲目信任了HTTP请求头里的洞验`Host`字段。你可能会说，这个字段不是浏览器自动填的吗？没错，但攻击者可以手工构造请求，把Host改成任意值。服务器如果不对其进行校验，就会把攻击者控制的域名拼进链接、重定向地址，甚至CSRF令牌里。

验证这个漏洞，不需要任何高级工具。用curl就够了。我常用的一个测试方法是：curl -I http://target.com/ -H "Host: evil.com"，然后看响应里的Location或Set-Cookie字段是否包含evil.com。如果出现了，基本就中招了。另一个更隐蔽的场景是密码重置功能。正常流程下，用户请求重置密码，服务器会生成一个包含域名的链接发到邮箱。我拦截这个请求，把Host改成自己的域名，如果服务器没有校验，那么发给用户的邮件里，那个重置链接就会指向我的服务器。用户点击后，请求带着重置令牌打到我的机器上，我就能用它去重置别人的密码。

有一次，我在一个开源电商系统上做测试。它的邮件模板里直接用了request.getServerName()来拼接链接。我把Host改成`attacker.com`后，收到的密码重置邮件果然指向了`http://attacker.com/reset?token=xxx`。更讽刺的是，这个系统的管理员后台登录页也有同样的问题，登录表单的action属性指向了伪造的Host，意味着如果管理员在登录时被中间人篡改了Host，他的凭证就可能被发送到攻击者服务器。

当然，不是所有Host头攻击都这么容易利用。有些框架会默认使用相对路径，那就无所谓了。但凡是涉及到绝对URL生成的地方，比如邮件通知、OAuth回调、OpenID重定向，都值得测一测。还有个容易忽略的点——CDN或反向代理后的应用。如果你直接访问源站IP，而源站又信任了Host头，那就可以绕过CDN的防护，直接攻击源站。我见过一个案例，某银行系统的客服后台绑定了域名白名单，但开发环境没做校验，攻击者通过伪造Host头直接访问了内网的管理接口。

修复方法其实很简单。最稳妥的是在服务器层面校验Host白名单，比如Nginx里加一条if ($host !~* ^(example\.com|www\.example\.com)$) { return 403; }。应用层也要注意，不要直接用`request.getHeader("Host")`，而是用配置好的serverName。另外，如果用了Spring Security，可以开启`ServerNameRequestMatcher`来限制。

写这篇验证文章的时候，我特意又试了下某知名云服务商的控制台。它的登录接口把Host写死在了代码里，怎么改都不认。而另一家小公司的后台，则毫无防备——它的密码重置邮件里，域名直接来自Host字段。同样的漏洞，不同的命运。差距不在技术难度，而在安全意识。你手头的系统，属于哪一种？