凌晨两点，头攻我盯着Burp Suite的击漏拦截面板，看着那个被我改成`Host: evil.com`的头攻请求包，心跳有点快。击漏三秒后，头攻服务器返回了200 OK，击漏页面里赫然写着“欢迎回来，头攻admin”。击漏这不是头攻什么高深的漏洞，就是击漏一次普通的HTTP Host头攻击——但它的杀伤力，往往被开发者严重低估。头攻

Host头是击漏什么？说白了，就是头攻你在浏览器地址栏输入网址后，HTTP请求里自动带上的击漏一行字段，告诉服务器“我要访问的头攻是哪个域名”。问题在于——很多服务器根本不验证这个字段的真实性。它们只关心一件事：Host头里写了什么，我就按什么来处理。于是，攻击者可以堂而皇之地把Host改成任何值，服务器照单全收。

有个真实案例我印象特别深。某电商平台的密码重置功能，用户点击“忘记密码”后，系统会生成一个包含重置链接的邮件。链接长这样：`https://reset.your-shop.com/token=abc123`。攻击者把自己的域名填进Host头，服务器生成的重置链接就变成了`https://evil.com/token=abc123`。受害者收到邮件，点开链接——如果他的邮件客户端渲染了HTML，或者他手滑点了那个看起来无害的链接，token就跟着请求发送到了攻击者的服务器。密码重置的令牌到手，账户等于拱手让人。

更隐蔽的攻击场景在代理服务器后面。有些内网应用，管理员通过`http://192.168.1.10`访问后台，Host头自然是IP地址。攻击者如果知道这个IP，直接构造一个带恶意Host的请求，就能让服务器把响应发送到指定位置——这叫“缓存投毒”的变种。我见过最离谱的一次，某企业内部的运维平台，因为Host头没校验，攻击者甚至能诱导服务器发起任意URL的请求，直接变成SSRF（服务端请求伪造）漏洞。

修复方法说起来简单：在服务器端明确配置允许的Host白名单。Nginx里写一行`server_name`，Apache里用`ServerAlias`，Spring Boot加个`server.address`校验——几分钟的事。但现实是，很多老项目根本没人动过这块配置。我审计过的代码里，至少六成后端框架默认不开启Host校验。开发者的逻辑是：“反正我的服务器只服务一个域名，谁会那么闲去改Host头？”——可攻击者就是这么闲。

有个细节被大多数人忽略了：Host头攻击不只是改一个字段那么简单。它还能绕过访问控制。比如，某些应用的URL重定向逻辑依赖Host头做判断，`if (request.getHeader("Host").equals("admin.example.com"))`——攻击者直接把Host改成`admin.example.com`，哪怕他访问的是公网IP，服务器也会把他当成内部管理员。我做过一次测试，某政务网站的统计后台，就用这种方式做了IP白名单的“补充验证”，结果绕过只需要一行curl命令。

说实话，这个漏洞技术含量不高，但它考验的是开发者的“信任边界”意识。你默认信任了客户端传来的一个关键参数，却没有校验它的合法性——这在安全设计里是大忌。就像你家的门锁，钥匙上刻着“主卧”两个字，你就认为拿这把钥匙的人一定是主人？

写到这里，我打开终端，随手对一个政府网站发了个带恶意Host的请求——响应头里清清楚楚地返回了`Location: https://evil.com/login`。这个漏洞，比想象中更常见。别觉得这种事离你很远，你负责的那个系统，可能正裸奔在互联网上。去查查你的Nginx配置吧，就现在。

(责任编辑：探索)