Nginx正则过滤SQL注入与XSS：反代层安全拦截实战指南

1. 整体设计与思路拆解

1.1 为什么把过滤放在 Nginx 这一层

先说结论：Nginx 过滤规则不是应用安全的银弹，但它是最容易被低估的一道入口拦截。大部分 Web 应用的安全检查都放在业务代码里，比如登录接口校验输入、ORM 参数化查询、Razor 模板自动转义等等。问题是，代码审查节奏一快，业务接口几百条，总有几个历史接口是裸奔的。这时候如果能在大门口先拦一道，哪怕规则写得粗糙一点，也能把大量通用目录扫描、自动化攻击脚本挡在业务被拖垮之前。

我做过的某个项目里，后端所有接口都用了参数化查询，理论上 SQL 注入漏洞很少。但运维侧还是发现有异常 IP 持续请求/search.php?id=1 and sleep(5)之类的路径。这类请求如果没有 Nginx 拦截，会真实打到 PHP-FPM 进程上，每个请求白白占用一个 worker，几十个并发就能把服务拖到响应超时。加一层过滤之后，同一类请求在接入层直接 403，后端进程根本不用起床。

适合谁参考这个方案？主要是以下三类人：一是运维手里管着很多网站，来不及逐个改业务代码；二是开发兼运维，需要快速加固一个已经上线的系统；三是做安全测试的朋友，想理解反代层过滤规则的常见写法，方便评估绕过面。无论哪一类，核心思路都一样：在请求路由到应用之前，先按特征快速决定放行还是拒绝。

1.2 攻击特征与 Nginx 过滤的契合点

SQL 注入的经典特征是请求中出现数据库操作片段，比如union select、sleep(3)、benchmark、information_schema、into outfile。XSS 的经典特征更直观，比如<script>、onerror、javascript:、alert(1)这类片段出现在 URL 参数、表单提交内容或 Cookie 里。

Nginx 本身不解析业务参数，但它能看到完整的$request_uri、$args、$http_user_agent、$request_body这些原始文本。攻击者的 payload 无论怎么编码，最终总要落到这些字符串里。用正则把这些原始字符串扫一遍，命中疑似攻击特征就返回 403，这就是整个方案的全部原理。

需要强调的是，这个方案是“粗过滤”而不是“深度检测”。它能挡住的是那些特征明显的廉价攻击，真正高水平的定向攻击往往会做充分编码混淆，靠正则很难面面俱到。所以正确心态是：Nginx 过滤规则做第一道闸门，业务层参数化查询、输出转义依然要做，后端的 WAF 或风控系统也建议保留。层与层之间是互补关系，不是替代关系。

1.3 方案选型时的两点纠结

有人会问：直接用开源 WAF 模块不是更省事？比如搭配 Lua 的 WAF 方案确实能做得更细，能做状态管理、频率限制、精细化规则上下文。但如果只是为了快速止血，引入额外模块意味着重新编译 Nginx、维护一套更复杂的配置文件、承受额外的内存和 CPU 开销。对于中小网站，原生的if + $request_uri + return 403已经能挡住七八成脚本小子的乱打。

还有人会纠结该用return 403还是rewrite到某个提示页。我的经验是：一律return 403，不要做跳转。跳转会多一次请求，也会让扫描器确认目标存在交互性；直接 403 干净利落，日志里也容易统计拦截次数。

2. 核心细节解析与实操要点

2.1 Nginx 配置层级和匹配流程

写过滤规则之前，先把 Nginx 的处理顺序理清楚。请求进来后，Nginx 会经过以下阶段：解析 HTTP 头部和 URI → 按 server_name 匹配虚拟主机 → 按 location 前缀/正则匹配路径 → 执行该 location 内的 rewrite、if、proxy_pass 等指令。如果我们在最外层 server 块里定义规则，则所有 location 都会继承；如果在某个 location 内部定义，则只有该路径生效。

实操中建议在server块顶部放通用过滤规则，在特定敏感 location 里再叠加更严格的规则。比如所有接口都防 SQL 注入，但只有/api/upload这个路径额外检查文件内容相关参数，这种层级关系更灵活。如果统一定在http块，作用域全局生效但无法做到某个站独享配置，一般不建议，除非你明确知道所有站点都适用同一套标准。

这里要说一个老梗：Nginx 里if指令被官方文档称作“邪恶的”，因为它在某些场景下行为反直觉，比如if内写proxy_pass会引起指令上下文混乱。但用在return这种纯响应指令上是安全的。我们只做“命中即返回 403”，不做复杂的跳转或转发，正好规避了那个经典坑。

2.2 常用正则的关键点和防误伤原则

先看最基础的过滤正则。假设我们防护 SQL 注入和 XSS，配置大概长这样：

# 统一拦截疑似注入与跨站脚本特征 if ($request_uri ~* "(union[\s]+select|select[\s]+.*?from|sleep\(|benchmark\(|concat\(|load_file\(|into[\s]+outfile|information_schema\.|<(script|iframe)[\s\S]*?(alert|javascript|onerror)>)") { return 403; }

逐段拆开理解一下：

• union[\s]+select：匹配union select，[\s]+兼容多个空格、换行、制表符。为什么强调多空格？因为有些扫描器会故意构造union/*!*/select或union select来绕过简单的union select匹配。
• select[\s]+.*?from：匹配select ... from这种典型的查询结构。.*?是非贪婪匹配，能跨任意字符。这个正则杀伤力大，误报率也高，如果站点本身有英文单词“select”出现在 URL 里，就要小心了，后续会专门讲怎么降误伤。
• sleep\(|benchmark\(：匹配延时注入常见的函数调用。\(转义左括号，避免匹配到字段名前缀里的sleep单词。
• information_schema\.：匹配数据库元信息查询特征，后面跟的是点号，因为正常请求里出现这个库名的概率极低。
• <(script|iframe)[\s\S]*?(alert|javascript|onerror)>：匹配<script>...alert...这类经典 XSS 载荷。[\s\S]表示任意字符包括换行，防止 payload 里拆成多行绕过。

XSS 方面单独再补一组针对事件处理器的正则：

if ($request_uri ~* "(on(load|error|click|mouseover|focus|blur)[\s]*=|javascript:|eval\(|alert\(|document\.cookie|String\.fromCharCode)") { return 403; }

事件处理器是 XSS 的重灾区，攻击者经常注册<img src=x onerror=alert(1)>，URL 里onerror=这个特征非常明显。javascript:冒号协议也值得拦，因为浏览器执行 javascript 伪协议的场景在现代 Web 里基本只有攻击者会用。

2.3 编码绕过问题，靠正则怎么补

URL 里的字符可以百分号编码。select写成%73elect、<script>写成%3Cscript%3E，这是最基础的绕过姿势。上面正则匹配的是原始$request_uri，遇到百分号编码就失效了，所以必须在正则里把常见编码形态也覆盖进去。

例：union select整句编码后是union%20select，原正则无法匹配，因为%和数字不是[\s]。可以补一个等效匹配：

if ($request_uri ~* "(union|select|sleep|benchmark|information_schema|script|alert|onerror)[\s%20]{0,3}") { return 403; }

但这里要非常谨慎，因为[\s%20]{0,3}这种写法会宽松到离谱。比如 URL 里出现“select 下拉框的图片 src”，就可能因为匹配到select而误杀。实操上我通常只对明显攻击特征做编码兼容，例如%27（单引号）、%3C（小于号）、%3E（大于号）、%20（空格）。

更稳妥的方案是分两步：先用$args拿到参数原始串，再做一层rewrite by Lua解码后检测。但这里不展开，因为目标是原生 Nginx。原生环境能做的就是多列几组特征，把常规的单次 URL 编码覆盖住。双重编码、畸形编码这类更深层的绕过，坦白讲原生正则很难防全，得靠业务层或专业的 WAF 引擎来处理。

2.4 不同请求位置的分工

一套规则不可能覆盖所有位置，需要按变量拆开处理：

其中$request_uri自带完整 URL 含参数，所以最常用的就是它。$uri是解码后的规范化路径，不含参数，适合精确匹配路径是否在黑白名单里。$request_body在 Nginx 原生环境里有点特殊，后面单独说。

3. 实操过程与核心环节实现

3.1 一套可以直接落地的基础配置

下面是模拟项目里使用过的一套完整配置，去掉了业务相关路径，保留了通用规则。直接放在server块内即可生效。

## 基础过滤：SQL 注入特征 if ($request_uri ~* "(union[\s]+select[\s]+.*?from|union[\s]+all[\s]+select|select.*?from.*?where|sleep\([\s]*[0-9]+|benchmark\([\s]*[0-9]+|load_file\(|into[\s]+outfile|into[\s]+dumpfile|information_schema\.|order[\s]+by[\s]+[0-9]{1,3}|\/\*.*?\*\/)") { return 403; } ## 基础过滤：数据库函数和命令执行特征 if ($request_uri ~* "(extractvalue\(|updatexml\(|exp\(|floor\(rand\(|group_concat\(|concat_ws\(|char\(|ascii\(|substring\(|mid\(|--[\s]+|-{2,}|#$)") { return 403; } ## XSS 特征：脚本标签和事件处理器 if ($request_uri ~* "(<|%3C)[\/]?(script|iframe|object|embed|svg|img|math)[\s\S]*(>|%3E)") { return 403; } if ($request_uri ~* "(on(load|error|click|mouseover|mouseout|focus|blur|submit|change)[\s]*=|javascript:|vbscript:|expression\(|eval\(|document\.cookie|String\.fromCharCode|windows\.open)") { return 403; }

配置解读，为什么这几条是基础配置：

第一，不允许--和#。这两个符号是 SQL 注释符，注入里经常用来把原本的 SQL 后半句注释掉，达到截断逻辑的目的。不过#在 URL 里本来就是 fragment 分隔符，正常浏览器不会把#后边的内容发给服务器，所以标题 URL 参数里出现#大概率是攻击脚本硬拼的。

第二，不允许/* */块注释。MySQL 还有/*!50000 union select */这类版本化注释，很多扫描器拿来混淆。这个正则也没有全防，只是把常见形态先兜住。

第三，${'exp\0000'}这段是我写错了吧。别在线上抄，那是我临时打的废话。实际用exp\(来匹配数学函数exp()，它被利用是因为 MySQL 7 版本在某些运算溢出时报错回显，但属于小众漏洞，可以放也可以不放。保守起见建议放。

第四，XSS 的正则里，[\/]?是为了兼容闭合标签</script>。有些扫描器会把整段 payload 原样丢到参数里，检测闭合标签能多抓一类。它不完美，可挡常规攻击够用。

3.2 重定向策略：拦截和放行的比例控制

回到那套配置，有没有发现我没有写return 444？那个也是很多加固教程里常见的写法，直接断开连接不返回任何内容。return 444对扫描器来说等于石沉大海，有时候比 403 更好用，因为攻击者不确定目标服务是否存活，后续探测节奏会变慢。

但反过来看，没有响应状态码也意味着我们的日志里没有 response code，无法快速判断“这条请求是被刻意丢弃的”。所以我的习惯是：对直连接入的扫描流量用return 403，对疑似同行反向代理转发的异常请求用return 444。前者方便审计，后者让对端代理先怀疑人生。这个细节各位按自己的监控习惯选择，不是硬性要求。

3.3 POST 请求体的过滤怎么处理

开头说过$request_body是原生 Nginx 的老大难。如果直接在普通server配置里读取$request_body，会出现两个问题：一是读取过一次之后，proxy_pass转发到后端时 body 就没了，业务接口收到空 body；二是大 body 读进内存，容易把 Nginx 进程内存吃满。

推荐两种落地方式。

第一种，Nginx 原生条件下，在location里使用limit_except先压制请求方法，然后对$request_uri做过滤，不读 body。POST 请求的 body 过滤交给业务层。这样做只能防一半，但能提供基础防护：

location /api/ { limit_except GET POST { deny all; } if ($request_uri ~* "(union[\s]+select|sleep\(|benchmark\(|<script|onerror=|javascript:)") { return 403; } proxy_pass http://backend; }

第二种，用 OpenResty 的 Lua 模块读取 body 并检查。这段不是原生 Nginx，不深入展开，但给个思路：

local body = ngx.req.get_body_data() if body and ngx.re.match(body, "(union%s+select|sleep%(%d+)|<script%s*>)") then return ngx.exit(403) end

多数中小团队其实没必要为了 body 过滤专门引入 Lua，因为只要业务层用了参数化查询，body 里的注入基本打不穿数据库。反而靠正则硬拦 body 会拦出很多“误杀朋友”。真实场景里，POST 表单里有一个字段叫“描述”，用户上传一段包含sleep(3)的文本，你的规则就把他拦了，这体验太差了。

3.4 部署和验证的完整流程

改完配置先全局检查语法，这是老运维都会做的事，但新手很容易漏：

nginx -t

输出syntax is ok之后再平滑重载：

nginx -s reload

重载是平滑的，不会中断在线请求，但保险起见还是建议在低峰期操作。然后验证规则是否生效，用 curl 模拟攻击请求：

# 模拟 SQL 注入 curl -I "http://your-server.com/index.php?id=1%20union%20select%201,2,3" # 模拟 XSS curl -I "http://your-server.com/search?kw=%3Cscript%3Ealert(1)%3C/script%3E" # 正常请求，预期不受影响 curl -I "http://your-server.com/index.php?id=100"

前两个请求返回403 Forbidden，健康请求返回正常状态码，说明规则生效。这一步务必做，不然你以为配上了，实际上正则写错导致所有请求都 404，排查起来更费劲。

4. 常见问题与排查技巧实录

4.1 误拦截了正常请求怎么办

这是上线过滤规则后最多人骂的场景。经典案例是商城站点搜索商品，用户在地址栏输入参数kw=select或者某个商品型号里包含sleep5。命中规则，403，客户直接投诉“商品搜不了了”。

我的处理思路是分级降噪。

第一层，能不写宽泛关键词就不写。比如select这种英文单词，除非你的站点是纯技术站点，否则建议配合union、from、where同时出现才拦。单纯一个select拦下来，误伤概率极高。上面基础配置里select.*?from.*?where已经比裸select强很多。

第二层，按路径细分。后台管理接口、登录接口、数据库管理页面这些路径严格要求；前台商品详情、搜索页这类公开页面只拦明显特征如<script、alert(这种，不拦select from where组合。具体判断是不是该对参数值里的英文词组放宽，得看业务场景。

第三层，观察一段时间再松动规则。规则上线一周后，把 403 的日志翻出来，逐个看被拦的 URL，凡是带正常业务关键词的，把规则改成更精确的变体。比如把select[\s]+.*?from改成union[\s]+select加from.*?where的组合，误伤面会小很多。

如果不想这么麻烦，还有一个投机的做法：统一拦截后返回 403，再对少量放行的业务 URL 做白名单。比如把需要支持“select 关键词搜索”的页面路径加进location白名单里，在里面用allow all和deny all按 IP 或路径放行，绕开全局规则。但白名单最好别开太多，开了就是给攻击者留后门。

4.2 攻击者做了编码变换，正则还能拦吗

百分号编码、大小写混淆能拦大部分，但还有更刁钻的。比如un%69on sele%63t，把i和c编码掉，普通正则是瞎的。Nginx 的$uri变量是经过 URL 解码的规范化路径，但$request_uri是原始未解码串。如果想让匹配更鬼，可以改用$uri加$arg_xxx组合，因为$arg_xxx变量会自动解码参数值。

例如请求/search?kw=un%69on%20sele%63t，$request_uri里是编码形态，把规则改成匹配$arg_kw，拿到的就是解码后的union select，直接命中：

if ($arg_kw ~* "(union[\s]+select|sleep\(|benchmark\(|<script|onerror)") { return 403; }

这里也要小心：$arg_kw只对应名为kw的参数，如果攻击者换参数名就成了漏网之鱼。还得配合$request_uri的粗筛。双重编码、三重编码这类变形，原生 Nginx 确实防不住，别勉强，后面还有业务层守着。

4.3 用户请求体里带着扫描痕迹被误伤

POST 表单里如果有一大段富文本内容，比如用户复制了一段包含select from英文的技术文章，或者论坛讨论区有人发帖讨论onerror事件写法，可能被误杀。这个问题在正文过滤里永远存在，防不胜防。

我的建议是，POST body 的过滤规则只对特定路径开，比如登录接口、注册接口、修改密码接口这些对输入内容要求严格的位置；对评论、公告、富文本这类“用户生产内容”的路径，规则必须关掉或者只保留<script这种绝对攻击特征。宁可让少量 payload 进到业务层，也不能把正常内容交流全砍了。

4.4 日志分析时怎么区分拦截和正常流量

加了规则后，Nginx 日志默认会记录所有 403 请求。建议在 access log 格式里加一个专用字段，把拦截类型标记出来。方法很简单，每个if块里先执行set一个变量，最后统一在日志里打出来：

if ($request_uri ~* "(union[\s]+select)") { set $attack_type "sqli-union-select"; return 403; } if ($request_uri ~* "(<script)") { set $attack_type "xss-script-tag"; return 403; } log_format security '$remote_addr [$time_local] "$request" $status attack_type=$attack_type';

这样日志里每条 403 请求都能看出是哪种攻击类型被打掉了。平时用grep attack_type就能快速统计：今天哪个攻击路径打得多、哪个 IP 在扫端口、哪个特征经常误报。我维护的那台服务器上，最长一次持续监控三个月，发现大部分自动化流量来自固定的网段，最后直接在 Nginx 层写了 IP 黑名单，过滤规则的压力小了非常多。

4.5 正则性能会不会拖垮 Nginx

这是新手最容易担心的问题。其实 Nginx 处理几十条正则的耗时远小于一次后端数据库查询，CPU 开销基本可忽略。但有两个性能雷区：一是正则里用了灾难性回溯结构，比如.*?.*?套娃；二是每个请求都执行大量 Lua 脚本。原生正则过滤规则控制在二三十条以内，每条不带过深的嵌套，完全没问题。我那个配置跑了半年，Nginx worker 的 CPU 占用增加不到 1%。

5. 我踩过几次坑之后学会的几件事

第一件事，规则不是越严越好。一开始我为了“安全”把select、script、alert这些关键词全裸放在规则里，结果当天就把网站用户搜索“select”关键词的请求全拦了，被业务方追着骂了一下午。从那以后我给自己定了一条规矩：任何新正则上线前，必须在日志里先跑一天观察模式，而不是直接开启拦截。Nginx 没有 dry-run 模式，就手动把规则里的return 403改成access_log /var/log/nginx/waf.log attack_type=$attack_type;，只记录不拦截，等确认误报率低了再开杀。

第二件事，正则里一定要写~*不写~。差一个星号，大小写就敏感了，攻击者把<SCRIPT>一换就绕过，这种低级漏洞不能犯。

第三件事，别过度依赖反代层过滤，把业务代码安全防护也同步更新。反代层规则能替你挡住绝大多数无聊扫描，但真正的威胁会精心构造 payload，绕开你所有正则。这个过程里，业务层参数化查询、输出编码才是最后兜底的生命线。两者配合，服务才能睡得着觉。

如果你正准备给自己的服务器加这道闸门，建议就从本文的基础配置开始，先跑几天只记日志不拦截，再把误报率降到最低，然后切换成拦截模式。遇到奇怪的攻击 payload 可以顺手记下来，积累成自己的特征库，比网上抄来的大而全规则靠谱得多。