传统数据库防火墙在云原生环境中对sql注入基本无效，因其仅监控数据库网络层流量，而微服务直连、grpc载荷、orm预编译等场景均绕过检测；真正有效的是前置至envoy sidecar的sql语义解析+jwt scope校验+egress代理协同防御。
数据库防火墙在云原生里根本拦不住应用层SQL注入
直接说结论：传统数据库防火墙（如Oracle DFW、华为云DBS防火墙）对云原生环境下的SQL注入基本无效，除非你把所有SQL请求都强制走代理模式且关闭直连。原因很简单——它只监控到达数据库网络层的流量，而微服务间大量SQL语句根本不会经过它：user-service用JDBC直连MySQL，Sidecar不拦截；order-service调用payment-service的gRPC接口，payload里带SQL片段，DB防火墙完全看不见。
常见错误现象：SELECT * FROM users WHERE id = '1' OR '1'='1' 这类拼接SQL在业务代码里执行时，数据库防火墙日志里压根没这条语句——因为它是应用进程自己构造并发送的，不是从WAF或API网关转发来的。
- 数据库防火墙只能看到TCP流里的原始SQL（如MySQL协议包），但无法识别ORM生成的预编译语句、JDBC PreparedStatement参数绑定后的实际执行逻辑
- 若应用使用连接池（HikariCP、Druid），同一连接反复执行不同SQL，防火墙很难做上下文关联分析
- 云原生中Service Mesh已接管东西向流量，但DB防火墙不在数据平面内，属于旁路设备，存在检测盲区
真正起作用的是Service Mesh + SQL语义解析服务协同
要让SQL注入在云原生里被实时拦截，必须把检测点前移到应用出口，也就是Envoy Sidecar。但Envoy本身不解析SQL，得靠ext_authz过滤器把请求发给独立的SQL检测服务。
实操关键点：
- 必须启用
http_connection_manager并配置router和ext_authz两个过滤器，否则Envoy只是透传，连body都拿不到 - 对JSON API，需确保
ext_authz能读取request_body，并在ext_authz配置里显式设置with_request_body: { max_request_bytes: 1048576 } - 检测服务推荐用轻量Go实现，基于
libinjection或SQLite parser做语义分析，不要在Filter里写Lua做正则匹配——' OR 1=1 --能拦，0x554e494f4e（UNION十六进制）就绕过了 - 超时必须设为
200ms以内，失败策略建议allow_if_no_response: true，避免检测服务抖动拖垮整个链路
云平台WAF规则必须开启JSON解析与语义引擎
如果你用的是阿里云/腾讯云WAF，别只开“SQL注入防护”开关就完事。默认情况下，WAF对{"q":"admin'--"}这种JSON body是不解析的，它只看query string和form-data。
检查并操作以下配置项：
- 在WAF控制台 → Web攻击防护 → SQL注入 → 确认“JSON解析”已开启（阿里云叫“深度JSON解析”，腾讯云叫“Body内容检测”）
- 动作必须设为
拦截，不能是观察或放行；尤其对/api/v1/search这类路径，建议加自定义规则：request_uri contains "/api/" and libinjection_is_sqli == true - 禁用“宽松模式”：该模式会跳过大小写混用、注释绕过（如
SEL/**/ECT）、空格替换为%09等变种检测 - 注意WAF对
POST /graphql请求的支持有限，GraphQL查询需额外配置自定义规则匹配query字段中的SQL关键词
最容易被忽略的egress和JWT scope校验
很多人配完Sidecar和WAF就以为高枕无忧，结果攻击者用合法token直连数据库照样打穿——问题出在信任边界没划清。
两个硬伤必须补上：
-
egress流量默认不受控：Envoy Sidecar默认只拦截ingress，order-service如果直连MySQL，它的出站SQL请求Sidecar根本不看。必须显式配置egress监听器，并启用mysql_proxy或tcp_proxy过滤器做协议解析 - JWT校验不能只验签名：Envoy的
jwks_authn默认只校验kid和signature，攻击者可用一个scope: ["db:read"]合法token发起DROP TABLE，因为scope字段没被策略引用。需在ext_authz里显式提取headers["authorization"]并校验scope是否匹配当前接口权限
复杂点在于：SQL语义分析、JWT scope、egress代理三者必须在同一个调用链里完成决策，不能拆成三次独立RPC。否则延迟叠加+失败策略冲突，反而降低可用性。
