hostheader攻击漏洞验证测试

我拿自己的漏洞博客做了个实验，改了改HTTP请求里的验证Host字段，结果后台管理后台直接跳到了另一个域名上。测试这不算新鲜事，漏洞但真正让我后背发凉的验证是——密码重置邮件里的链接，也跟着变了。测试

Host Header攻击的漏洞原理不复杂。服务器处理请求时，验证很多时候直接信任了HTTP头里的测试Host字段，用它来生成绝对链接、漏洞做虚拟主机路由、验证甚至校验安全令牌。测试攻击者只需要把Host改成自己的漏洞域名，就能让服务器把敏感信息发到错误的验证地方。我见过最蠢的测试案例是某电商平台，重置密码的token直接拼在URL里，而那个URL的域名完全由Host字段控制。改一下，token就进了攻击者的口袋。

验证方法其实很粗暴。用curl或者Burp Suite，抓到正常请求，把Host字段替换成你控制的域名，看响应里的Location、Set-Cookie、或者任何URL生成逻辑是否跟着变。我测试的时候，发现只要改Host，登录后的跳转地址就变成了`http://evil.com/dashboard`。浏览器地址栏没变，但后台的CSRF token生成逻辑里，baseURL已经错了。

更隐蔽的坑在CDN和反向代理后面。有些配置会把原始Host透传，有些则会覆盖。我试过一个内网系统，Nginx设置了`proxy_set_header Host $host`，这行配置直接把用户可控的Host透传给了后端应用。后端Java代码用`request.getServerName()`拼URL，结果就是攻击者可以伪造任意域名的回调。真实环境里，这种问题在微服务网关层特别常见，因为网关往往只校验路径，不校验Host是否在白名单内。

修复方案不复杂，但实施起来容易漏。最直接的办法是在服务器层面强制校验Host——Nginx里加一段`if ($host !~* ^(example\.com|www\.example\.com)$) { return 444; }`，或者用更规范的`server_name`匹配规则。应用代码里别用`getServerName()`，改成读配置文件的固定域名。还有就是，密码重置这类高价值操作，链接里的域名必须硬编码，不能动态拼接。

我这轮测试还发现一个反直觉的现象：很多框架自带的Host校验形同虚设。比如某些Python框架，默认接受任意Host，只有显式配置`ALLOWED_HOSTS`才安全。而不少开发团队压根不知道这个配置项的存在。测试的时候，我随便改了Host为`localhost`，应用居然正常响应了，连个警告都没给。

最后说点个人感受。这类漏洞属于“知道的人觉得低级，不知道的人踩坑无数”。它不像SQL注入那样有直观的报错，也不像XSS那样能看到弹窗。但危害是实打实的——我甚至用这个漏洞配合DNS rebinding，绕过了某个后台的IP白名单限制。所以，别小看这个字段。每个写后端的人，都应该在代码审查时问一句：这段逻辑里的域名，是用户可控的吗？

本文地址：http://www.79wt.cn/news/554d9099355.html