Nginx本身不解析SQL,防注入只有两条路:一是用if+return做关键词粗筛,仅拦截显性攻击且不读请求体;二是编译加载nginx-modsecurity实现深度检测,但需严格配置SecRequestBodyAccess On、SecRuleEngine On及CRS规则,缺一不可。

直接用 Ingress 控制器集成 WAF,别碰 Istio 原生策略
Istio 本身不解析 SQL 语法,VirtualService 的 match.uri 或 headers 正则根本拦不住 URL 编码、大小写混淆、注释绕过的 ' OR 1=1 --。硬塞 WasmPlugin 虽可行,但要自己编译 Wasm 模块、手动解析 JSON body、规则无法热更新,还增加 0.5–2ms 延迟——生产环境得不偿失。
真正落地快、维护省的方式是:在流量入口层(即 Ingress)绑定成熟 WAF 引擎。主流选择有三:
- NGINX Ingress +
modsecurity-snippet注解(轻量、调试快,适合测试或小规模) - AKS 集群配 Azure Application Gateway + WAF 策略(托管规则集开箱即用,支持 OWASP CRS 3.x)
- 阿里云/腾讯云 ACK 集群直挂云 WAF(自动识别 JSON body、支持语义分析,且审计日志独立存储)
NGINX Ingress 注解式加固的关键配置项
如果你用的是社区版 NGINX Ingress Controller,modsecurity-snippet 是最直接的切入点,但必须配对启用,单开一条规则没用。
- 先打开引擎:
nginx.ingress.kubernetes.io/modsecurity-rule-engine: "On"(别用DetectionOnly上线,它只记录不拦截) - 加 SQLi 规则时注意匹配范围:
SecRule ARGS "@rx (?i)union.*select|or\s+1\s*=\s*1|information_schema" "id:101,deny,status:403,msg:'SQL Injection Attempt'"——ARGS覆盖 query string 和 form-data,但对 JSON body 无效 - 若后端接收 JSON,必须额外开启
modsecurity-json-body(需 Ingress Controller v1.10+ 且编译时启用 libjsonc) - 高危路径如
/login或/api/v1/users可单独加白名单网段:nginx.ingress.kubernetes.io/whitelist-source-range: "10.0.0.0/8",但这只是 nginx 层访问控制,不是 WAF 白名单
云厂商 WAF 必须确认的三项开关
阿里云 Web 应用防火墙、腾讯云 WAF、Azure WAF 都默认关闭 SQL 注入拦截动作,只留“观察模式”——这是线上事故最高发点。
评估 Kubernetes 集群安全态势,覆盖 RBAC、工作负载安全、网络策略、基础设施即代码(IaC)、运行时监控和密钥管理等 30 项控制项……
- 登录控制台,路径必须走到:
Web 攻击防护 → SQL 注入 → 动作设为“拦截”(不是“仅记录”,也不是“放行”) - 确认 JSON 解析已启用:腾讯云叫「JSON 深度检测」,阿里云叫「POST JSON 内容检测」,不开则
{"q":"admin'--"}这类载荷直接漏过 - 数据库审计服务必须旁路部署,且日志存到独立 OSS/Bucket;如果审计 Agent 和业务 DB 在同一节点,或日志写进同一个 RDS 实例,攻击者拿到 DBA 权限后第一件事就是删审计表
别忽略数据库端口暴露这个底层风险
再强的 WAF 也挡不住绕过入口的直连攻击。微服务架构里,backend-service 如果直接暴露 3306 端口到公网,攻击者可跳过所有 Ingress/WAF,用 mysql -h x.x.x.x -P 3306 -u root -p 尝试暴力破解或利用 CVE-2023-21912 这类认证绕过漏洞。
正确做法只有两个:
- 在云防火墙(CFW)或 NSG 中,把数据库端口(
3306、5432、1433)的入向规则限制为仅允许集群内 CIDR(如10.244.0.0/16) - 数据库服务本身禁用公网 IP,只绑 Pod 网络或私有子网,配合 NetworkPolicy 限制
backend-service的出口目标为 DB Service 名称
WAF 拦截的是 HTTP 流量,不是 TCP 连接。这层网络隔离不做,等于给 SQL 注入留了后门。

















