Nginx rewrite规则本身是高风险配置点，非防护手段；必须禁用基于$host或用户参数的动态重定向，改用$server_name、map+return白名单及正则拦截危险参数，并规避CVE-2026-42945漏洞相关写法。
在安全审计中，Nginx 的 rewrite 规则本身不是防护手段，而是高风险配置点——它容易被误用于开放重定向、Host 头劫持或成为 CVE-2026-42945（NGINX Rift）漏洞的触发入口。防范关键不在于“怎么写 rewrite”，而在于“哪些 rewrite 绝对不能写”以及“如何用更安全的指令替代它”。
禁用基于 $host 或用户参数的动态重定向
攻击者常通过伪造 Host 头或注入 redirect 参数实现跳转劫持。以下写法必须从配置中清除：
-
return 301 https://$host$request_uri;→ 改为return 301 https://$server_name$request_uri;（$server_name来自配置，不可篡改） -
rewrite ^/login$ /auth?redirect=$arg_redirect? last;→ 完全禁用，改用后端白名单控制跳转目标 - 任何含
$arg_*、$http_*、$cookie_*参与拼接 Location 或重定向路径的 rewrite 或 return 指令
用 map + return 替代 if + rewrite 实现跳转控制
if 在 location 块中行为不可靠，且 rewrite 会绕过早期拦截；推荐用 map 预定义可信跳转目标，并配合 return 精确响应：
- 在 http 块中定义合法跳转路径映射：
default "";
"/dashboard" "/dashboard";
"/profile" "/profile";
"/help" "/help";
}
- 在 login 路由中只允许命中 map 的值跳转：
if ($valid_redirect = "") { return 400; } return 302 $valid_redirect;
拦截非法重定向参数与危险字符
即使业务需支持跳转，也必须拒绝一切绝对 URL 和可疑结构：
- 用正则在请求初期拦截：
if ($args ~* "(redirect|next|url)=([^&]*://|//|@|\d{1,3}\.\d{1,3}\.)") { return 400; } - 禁止以
http://、https://、//、@、IP 地址或端口（如:8080）开头的参数值 - 对 OAuth 回调等敏感入口，额外校验
Referer并要求携带短期有效 Token（配合auth_request或 Lua 模块）
规避 rewrite 模块相关漏洞（CVE-2026-42945）
该堆溢出漏洞在特定 rewrite + if + 未命名捕获组 + 含问号替换字符串组合下触发。审计时重点检查：
- 是否出现连续使用
rewrite、if、set的嵌套逻辑 - rewrite 的 replacement 字符串是否含未转义的
?（例如rewrite ^/a/(.*)$ /b/$1?r=1;） - 是否存在
$1、$2等未命名捕获变量参与计算或拼接 - 确认 Nginx 版本 ≥ 1.30.1（开源版）或已打对应补丁（如 Plus R36 P4）
