http host头攻击漏洞如何验证

一个晴朗的头攻下午，我正给某客户的击漏内部系统做渗透测试。目标是洞何个老旧的OA系统，登录框干干净净，验证看不出什么毛病。头攻随手抓了个包，击漏发现HTTP请求里躺着个Host: 192.168.1.10。洞何我把它改成Host: evil.com，验证转发过去——响应页面里的头攻CSS链接全变成了http://evil.com/style.css。这就是击漏Host头攻击最典型的症状：服务器信任了客户端提供的Host值，直接拼进重定向或资源引用里。洞何

验证这漏洞，验证第一步先搞清服务器怎么用Host头。头攻最笨也最有效的击漏办法是改Host值看响应差异。拿curl试：

curl -I http://target.com/ -H "Host: test.com"

如果返回的洞何Location头或页面里的绝对URL跟着变，基本就中招了。但别急着下结论，有些服务器根本不看Host，或者做了白名单校验——那返回的可能还是原样，或者直接报400错误。报400反而是好事，说明它有防护；要是200且内容变了，漏洞实锤。

更隐蔽的场景是密码重置功能。我见过一个真实案例：某电商平台的重置链接长这样：http://target.com/reset?token=abc123，但邮件里的域名是从Host头取的。我把Host改成attacker.com，点击重置后，系统生成的邮件链接变成了http://attacker.com/reset?token=abc123。用户收不到邮件，但攻击者如果提前伪造Host并配合DNS欺骗，就能截获token。验证这种场景得小心，别真把用户邮件搞丢——最好在测试环境里造个假邮箱，或者直接看响应里的重定向地址。

还有个容易忽略的点：缓存投毒。如果服务器前面挂了CDN或反向代理，Host头可能被用来做缓存键。我试过一次，把Host改成evil.com，请求一个静态资源，结果代理把evil.com版本的响应缓存了，后续正常用户访问target.com时，居然拿到了带恶意Host的页面。验证方法很简单：连续发两个请求，第一个改Host，第二个恢复正常，看第二个响应是否被污染。这招对没做Host校验的代理特别灵。

手动验证够了，再用工具扫一遍。Burp Suite的Host头修改插件能自动化测试，但别全信——有些漏洞需要特定场景触发，比如配合X-Forwarded-Host头。有些服务器会同时信任Host和X-Forwarded-Host，后者优先级更高。我碰到过一个奇葩系统，明明校验了Host，却忽略了X-Forwarded-Host，改这个头照样能注入。所以测试时要多组合几个头，别只盯着Host。

最后提醒一句：验证和利用是两码事。发现Host头可篡改，不等于能造成实际危害。你得确认改完Host后，响应里的链接是否真的被用于后续请求。有些开发者会在后端强制拼接固定域名，前端显示变了但实际请求还是走原地址——那种情况只能算“伪漏洞”。真正有效的验证，是让改动影响业务逻辑，比如让密码重置邮件指向攻击者控制的域名，或者让缓存投毒影响其他用户。测到这一步，才算拿到实锤。

(责任编辑：焦点)