作为 Web 开发者，你是否曾忽略 HTTP 请求中的 Host 头？这个看似普通的字段，一旦被攻击者利用，可能导致密码重置劫持、缓存污染甚至服务器端请求伪造（SSRF）等严重安全问题。本文将从漏洞原理出发，分享 3 种经过实战验证的 Nginx 防御配置方案，帮助你快速筑牢 Web 应用的第一道防线。
一、HTTP Host 头攻击（Host Header Injection）：为什么它如此危险？
在 HTTP 协议中，Host 头用于指定请求的目标域名。但很多开发者不知道的是：Host 头由客户端完全控制，属于不可信数据 。这种因未校验 Host 头合法性导致的漏洞被称为HTTP Host 头注入漏洞（Host Header Injection），风险等级通常为中低，但利用场景广泛，可能引发严重连锁反应。如果后端应用直接使用这个字段生成 URL（比如密码重置链接、页面跳转地址），就会埋下巨大安全隐患。
举个典型场景：某网站的密码重置功能通过以下代码生成链接：
$resetUrl = "https://" . $_SERVER['HTTP_HOST'] . "/reset?token=" . $token;攻击者只需构造如下请求：
GET /forgot-password HTTP/1.1
Host: evil.com
User-Agent: Mozilla/5.0...用户收到的重置链接就会变成https://evil.com/reset?token=xxx。一旦用户点击，敏感的 token 就会泄露给攻击者，导致账号被盗。这种攻击方式成本极低，却能造成致命后果。根据 OWASP 安全测试指南，Host 头注入漏洞常被归类到"注入攻击"大类，是 Web 应用常见的配置类漏洞之一。
二、防御核心思路：Nginx 层拦截非法 Host
防御 Host 头攻击的关键在于 不要信任客户端传来的 Host 值。最佳实践是在 Nginx（反向代理层）提前校验 Host 头合法性，只允许预定义的合法域名通过。这样既能减少后端应用的压力，又能从源头阻断攻击。
核心原则：所有进入系统的 Host 头，必须在白名单内；不在白名单的请求，直接返回 403 拒绝访问。
三、3 种 Nginx 实战防御配置方案
方案一：单域名精确匹配（推荐，逻辑最清晰）
适用于只有一个主域名的场景，通过标志位判断 Host 是否合法，避免 Nginx 的 if 嵌套陷阱。
server {
listen 80;
server_name www.xlsys.cn; # 你的合法域名
# Host 头攻击防护配置
set $host_flag 0; # 初始化标志位为 0（非法）if ($host == "www.xlsys.cn") { # 匹配合法域名
set $host_flag 1; # 标志位置为 1（合法）}
if ($host_flag = 0) { # 非法 Host 直接拒绝
return 403;
}
location / {
root /www/h5;
index index.php index.html index.htm;
}
}这种方案的优势是逻辑简单，易于维护，即使是非专业运维也能快速理解和修改。
方案二：多域名白名单（主站 + 子站 / 测试环境）
如果你的应用有多个合法域名（比如主站 devresourcehub.com、子站 tools.devresourcehub.com、本地测试 localhost），可以用正则或多条件判断实现白名单。