云原生WAF需开启JSON解析开关并指定数据库类型才能有效防御SQL注入。它通过语义分析引擎解析SQL片段，替代传统正则匹配，并需联动数据库审计日志实现行为闭环验证。
云原生WAF能解析JSON body里的SQL片段
传统WAF默认只解析query string和form-data，对{"q":"admin' OR 1=1--"}这类JSON请求体完全无视——它把整个body当做一个字符串字段处理，不拆解、不解码、不还原语义。云原生WAF（如阿里云/腾讯云新版）必须手动开启「JSON解析开关」，否则sql_injection规则根本不会触发。
实操关键点：
- 在WAF控制台找到「防护规则 > SQL注入 > 高级设置」，勾选「启用JSON参数解析」
- 确认
content-type: application/json请求被纳入检测范围，否则即使开了开关也无效 - 若API用
application/vnd.api+json等自定义MIME类型，需额外添加到WAF的可解析类型白名单中
语义分析引擎替代了正则匹配
老式WAF靠SELECT|UNION|SLEEP这种正则关键词拦注入，但0x554e494f4e（UNION十六进制）、SeLeCt（大小写混用）、/**/UNION/**/SELECT（注释绕过）全都能穿过去。云原生WAF的语义引擎会把参数值当作SQL片段做词法解析，识别出admin' AND (SELECT COUNT(*) FROM users)>0--本质是布尔盲注，而不是比对字符串里有没有SELECT。
验证是否真生效：
- 查WAF日志，过滤
action: block且含fingerprint字段的条目——没这个字段说明还在用正则模式 - 用
id=1%20AND%20SLEEP(3)测试，响应头应带X-WAF-Action: blocked - 关闭语义引擎再测同一载荷，应变为放行或仅记录，否则配置未生效
必须指定数据库类型才能降低误报
GROUP_CONCAT在MySQL里合法，在MSSQL里就是错的；WAITFOR DELAY '0:0:5'是MSSQL延迟注入特征，MySQL压根不认。云原生WAF若不指定后端数据库类型，语义分析器无法判断哪些函数/语法属于攻击意图，要么放过真攻击，要么把正常业务SQL当威胁拦掉。
配置要点：
- 在规则组里为每个API路径绑定数据库类型，比如
/api/v1/report→mysql，/api/v1/audit→mssql - 避免全局设成
auto或留空，那等于退化回正则模式 - 若服务同时连多个库（如读MySQL、写PostgreSQL），需按出口路径拆分规则，不能混用
联动数据库审计日志做行为闭环
单靠WAF拦截只是“堵”，容易被绕过；结合数据库审计日志才能确认攻击是否真正抵达DB层。云原生WAF支持将拦截事件与RDS审计日志ID关联，比如WAF日志里出现request_id: req-abc123，数据库审计日志里也得有同ID的SELECT * FROM users WHERE id = '1' OR '1'='1'，才能确认这是真实攻击而非误报。
落地前提：
- 数据库必须开启全量SQL审计（不是仅错误日志），且时间精度至少到毫秒级
- WAF和DB实例需部署在同一云账号下，否则无法跨服务关联
request_id - 若用Druid/HikariCP连接池，注意审计日志里
client_hostname显示的是应用Pod IP，不是用户真实IP，需靠WAF透传X-Real-IP补全上下文
真正难的不是开开关，而是让WAF知道你用的是什么协议、什么数据库、什么编码方式——少配一个字段，0x554e494f4e就能直接进库。
