云原生中传统WAF和DB防火墙失效，因东西向流量绕过WAF、ORM预编译使正则失灵；须通过Envoy Sidecar配置http_connection_manager、router、ext_authz三过滤器，结合外部SQL语义解析服务实现应用出口级检测。
云原生环境下，单靠边缘WAF或数据库防火墙无法真正拦截SQL注入——东西向流量绕过WAF，直连数据库绕过DB防火墙，ORM预编译语句让传统正则规则失效。有效方案必须把检测点前移到应用出口，用Envoy Sidecar + 外部SQL语义解析服务协同实现。
为什么传统WAF和DB防火墙在云原生里基本失效
常见错误现象：SELECT * FROM users WHERE id = '1' OR '1'='1' 在user-service里拼接执行，WAF日志里查不到这条语句，DB防火墙也收不到原始SQL包。
- 边缘WAF只处理南北向流量，而微服务间70%以上调用是东西向（如
order-service→payment-service），根本不会经过它 - 数据库防火墙监听TCP层MySQL协议流，但
JDBC PreparedStatement、gRPC payload、JSON API body里的SQL片段完全不可见 - 连接池复用连接，同一socket反复执行不同SQL，防火墙无法做上下文关联分析
- JWT token若未校验
scope字段（如缺少db:read），攻击者可用合法token发起恶意查询
Envoy Sidecar必须配置的三个关键过滤器
Envoy默认只是透传代理，不解析L7内容，必须显式启用以下组件才能拿到SQL载荷：
-
http_connection_manager：必须启用，否则无法识别HTTP方法、Header、body等L7信息 -
router：必须配置，否则请求不会被路由到后端，ext_authz无法触发 -
ext_authz：将request_headers和request_body发给外部SQL检测服务；需在配置中显式设置with_request_body: { max_request_bytes: 1048576 }，否则body为空
若业务用gRPC，还需额外启用grpc_json_transcoder插件，否则protobuf payload中的SQL字段无法被提取。
SQL检测服务不能只靠正则匹配
直接在Envoy Filter里写lua正则规则，只能拦住' OR 1=1 --这类基础变形，对0x554e494f4e（UNION十六进制）、SeLeCt（大小写混用）、/**/UNION/**/SELECT（注释混淆）完全无效。
- 推荐用轻量Go服务调用
libinjection或SQLite parser做词法+语法解析，还原真实SQL意图（如识别admin' AND (SELECT COUNT(*) FROM users)>0--为布尔盲注） - 超时必须设为
200ms以内，避免检测服务抖动拖垮链路；失败策略设为allow_if_no_response: true - 高危路径（如
/api/v1/search）加硬约束：headers["content-type"] == "application/json" && body.size() ，防大payload绕过解析
云平台WAF语义引擎必须手动开启并验证
阿里云/腾讯云WAF控制台里点开“SQL注入防护”开关 ≠ 真正生效。默认规则集仅依赖关键字正则，语义分析引擎往往处于关闭或观察模式。
- 必须手动开启语义分析，并同步打开
JSON解析开关，否则{"q":"admin'--"}会被当普通字符串放过 - 务必在规则中指定数据库类型（
MySQL或MSSQL），语法差异会导致误报飙升 - 验证是否生效不能只看界面状态，要三重确认：① WAF日志中
sql_injection条目含fingerprint字段；② 用id=1%20AND%20SLEEP(3)测试是否被X-WAF-Action: blocked响应；③ 关闭语义引擎后同一载荷应变为放行或仅记录
真正难的不是配出能跑的规则，而是确保东西向流量全经Sidecar、egress出站受控、JWT scope校验严格、SQL检测服务低延迟高准确——漏掉任意一环，防护就形同虚设。
