凌晨两点，检测告警平台弹出一条橙色预警：检测到目标URL存在HTTP Host头攻击漏洞。到目目标是攻击我们自己刚上线的客户管理系统。我盯着那条记录，漏洞后背发凉——攻击者没有用任何复杂工具，检测只是到目把请求头里的Host字段改成了evil.com，服务器居然就信了。攻击

这不是漏洞危言耸听。Host头攻击的检测本质，是到目服务器盲目信任了HTTP请求里的Host字段，并基于这个不可信的攻击值去生成绝对链接、重置密码邮件、漏洞甚至执行路由逻辑。检测攻击者只要把Host改成自己的到目域名，就能诱导系统把敏感信息发到他的攻击服务器上。最典型的场景：你点了密码重置，邮件里的链接指向了攻击者的域名，他再转发给你，你输入新密码，密码就归他了。

我见过最讽刺的案例是某银行内部系统。开发团队花大价钱做了WAF、做了代码审计，却忘了在Nginx配置里固定server_name。结果安全测试员只改了Host头，就拿到了管理员密码重置链接。事后复盘，问题出在框架的url_for()函数——它默认用请求头里的Host拼URL，没人告诉它“只信配置里的那个域名”。

修复方法其实不难，但需要动三个层面。第一层是配置，在Nginx或Apache里显式声明server_name，并拒绝所有Host头不匹配的请求——直接返回403。第二层是代码，别用request.host拼绝对路径，要用配置项里的固定域名。第三层是防御纵深，在应用入口统一校验Host头是否在白名单内，白名单以外的直接丢弃。

但光改代码不够。我见过太多团队修完就完事，没人去验证邮件模板里那些硬编码的链接。测试时得模拟真实攻击：把Host改成attacker.com，看重置邮件链接是否指向恶意域名；改成不存在的域名，看是否报错泄露内部IP；甚至改成localhost，看会不会触发SSRF。每个环节都要测，尤其是那些用了反向代理的架构——代理转发时可能会覆盖Host头，你得确认最终到达应用服务器的是你期望的值。

还有个容易被忽略的点：CDN或负载均衡器可能会在转发请求时重写Host头。如果源站只校验自己的Host，但CDN传过来的已经是改写过的，就会误伤正常用户。所以校验逻辑得放在最外层，或者信任边界上。我习惯在Nginx层做第一道拦截，应用层再校验一次，双保险。

说到底，Host头攻击不是高深技术，它考验的是开发者的“默认不信”意识。就像你不会把门钥匙放在门口垫子下面，服务器也不该信任任何一个外部传入的字段。修完这个漏洞，我特意在代码评审清单里加了一条：所有生成绝对URL的地方，必须使用配置项，禁止引用请求头。过了两周，新来的同事在写导出功能时又踩了一次，被评审直接打回。这种坑，踩一次记不住，得用制度把它焊死。

(责任编辑：休闲)