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 注入拦截动作，只留“观察模式”——这是线上事故最高发点。
- 登录控制台，路径必须走到：
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 注入留了后门。
