ingress资源本身不解析请求体或执行规则匹配，sql注入拦截需依赖底层nginx-ingress控制器的modsecurity模块支持；仅可通过nginx.ingress.kubernetes.io/modsecurity-snippet注解注入规则，且须确保控制器已编译启用modsecurity、开启secrequestbodyaccess on并验证日志加载成功，否则规则静默失效。
不能直接在 Ingress 资源里写 SQL 注入拦截逻辑——Ingress 本身只是路由声明，不解析请求体、不执行规则匹配；真正起作用的是底层 Ingress Controller（如 nginx-ingress）及其扩展能力。
nginx-ingress 的 ModSecurity 集成方式
只有使用 nginx-ingress 控制器，并且它编译时启用了 ModSecurity 模块（常见于社区版或云厂商定制版），才能通过 Annotation 注入 WAF 规则。原生 Kubernetes Ingress 或 traefik/istio-ingress 不支持此能力。
-
nginx.ingress.kubernetes.io/modsecurity-snippet是唯一可用的注入点，例如：nginx.ingress.kubernetes.io/modsecurity-snippet: | SecRule ARGS "@rx (?i)union\s+select|exec\s+xp_cmdshell" "id:1001,deny,status:403,msg:'SQLi detected'"
- 正则必须转义空格和特殊字符（
\s+而非s+），否则 Nginx 启动失败 -
ARGS匹配 query string 和 form body，但对 JSON body 中的字段无效（需额外配置SecRequestBodyAccess On并启用 JSON 解析，这在多数生产部署中默认关闭） - 规则生效前必须确认控制器 Pod 日志里有
ModSecurity-nginx加载成功的提示，否则 annotation 被静默忽略
绕过风险与检测盲区
单纯靠字符串匹配极易被绕过，攻击者只需 URL 编码、大小写混用、插入注释或空格变形即可逃逸。比如 UNI%6FNS%65LECT 或 SEL/**/ECT 就不会触发 union select 规则。
- 不要依赖单条
@rx规则覆盖所有变种；应组合使用：ARGS_NAMES（检查参数名是否含sql、query）、REQUEST_BODY（配合SecRequestBodyAccess On）、QUERY_STRING - 避免在
modsecurity-snippet中写过于宽泛的规则（如@contains select），可能误杀正常业务字段（如{"action": "select", "type": "user"}） - 开启
nginx.ingress.kubernetes.io/modsecurity-rule-engine: "DetectionOnly"先观察一周流量，确认无误杀再切到On
更可靠的做法：前置专用 WAF
把 SQL 注入防护从 Ingress 层移出，交给专业组件处理，才是生产环境主流选择。
- 在 Ingress 前部署 Pipy、OpenResty 或云厂商 WAF（如阿里云 Web 应用防火墙），它们内置 libinjection 或 ML 模型识别 SQL 语义，不依赖简单正则
- 若必须保留在集群内，改用
Apache ShenYu网关替代 nginx-ingress：它提供 WAF 插件 + 可视化规则编辑界面，支持对 JSON body 字段级提取与上下文判断（例如排除sortField=sql这类白名单场景） - 别尝试用
WasmPlugin给 Istio 注入 SQLi 检测模块——Envoy Wasm 运行时限制多（无浮点、无动态内存）、JSON 解析需手写、规则无法热更新，实测延迟增加 1ms+，且维护成本远高于收益
真正容易被忽略的一点：所有基于 Ingress 的“拦截”都发生在反向代理层，无法替代应用层的参数化查询。哪怕 WAF 拦住了 99% 的攻击，只要后端还存在 string.format("SELECT * FROM user WHERE id = %s", userInput) 这类拼接，就仍存在绕过风险。
