单纯开启SQL注入防护开关不够，因默认规则仅依赖关键字正则匹配，无法识别注释混淆、大小写混用、字符串拼接等变形；需手动启用语义分析引擎，并配置JSON解析、指定数据库类型、联动数据库审计。
为什么单纯开“SQL注入防护”开关还不够
很多团队在云控制台点开 SQL 注入防护 就以为万事大吉，结果上线后仍被 ' OR 1=1 -- 或十六进制编码的 0x554e494f4e（即 UNION）绕过。根本原因是：默认规则集多为关键字正则匹配，对注释混淆（/**/、--）、大小写混用（UnIoN SeLeCt）、字符串拼接（CONCAT('SEL','ECT')）等变形毫无抵抗力。
语义分析引擎不是“增强版关键词扫描”，而是把请求参数当作 SQL 片段做词法解析，还原出真实意图。比如它能识别 admin' AND (SELECT COUNT(*) FROM users)>0-- 的结构本质是布尔盲注，而不是靠匹配 SELECT 字符串。
- 阿里云/腾讯云/华为云 WAF 的语义分析模块默认可能处于关闭或观察模式，需手动开启
- 该引擎依赖参数解析深度——若业务用 JSON 提交，必须同步打开
JSON 解析开关，否则{"q":"admin'--"}这类 payload 会被当普通字符串放过 - MySQL 和 MSSQL 的语法差异大，务必在规则配置中指定数据库类型，否则误报率飙升
如何确认语义分析引擎已真正生效
不能只看控制台里“已启用”三个字。真实生效需要三重验证：
- 检查日志：在 WAF 访问日志中搜索
sql_injection并筛选action: block，确认拦截记录里有带fingerprint字段的条目（这是语义引擎生成的指纹标识） - 主动探测：用已知变形载荷测试，例如
id=1%20AND%20SLEEP(3)（URL 编码延迟注入），观察是否被拦截且响应头含X-WAF-Action: blocked - 对比开关状态：关闭语义分析后，用同一载荷再测，应出现“仅记录”或“放行”；重新开启后必须变为
block，否则说明底层未加载词法分析器
特别注意：部分云厂商将语义分析与 智能防护 或 AI 模式 绑定，单独开 SQL 注入规则组 不等于开了语义层。
自定义规则必须配合语义引擎使用，否则形同虚设
很多人写一条“匹配 args 含 SELECT|INSERT|UPDATE 就拦截”的自定义规则，结果论坛发帖带 SELECT * FROM posts 被拦，或者真攻击用 SEL/**/ECT 成功绕过。问题出在：正则无法理解上下文。
- 正确做法是把自定义规则设为
触发条件 + 语义校验两段式：先用正则快速初筛（如args含单引号+括号），再交由语义引擎判断是否构成有效注入片段 - 高危路径（如
/api/v1/user、/search）建议加一条精准规则：request_uri 匹配 /api/.*user.* 且 libinjection_is_sqli 返回 true（部分平台支持调用底层 Libinjection 接口） - 禁用“宽松模式”或“兼容模式”——这些选项会跳过语义解析，退化为纯字符串比对
容易被忽略的部署细节：JSON 解析、数据库类型、审计联动
语义分析不是开个开关就一劳永逸的事。三个技术细节一旦漏配，整个防护链就断在第一环：
-
JSON 解析开关必须开启，且确认解析层级 ≥ 2（否则嵌套对象如{"filter":{"name":"' OR 1=1 --"}}无法展开） - 在 WAF 规则配置页明确选择后端数据库类型（
MySQL/MSSQL/PostgreSQL），不同方言的注释符、函数名、堆叠语法差异极大 - 语义引擎拦截只是第一步，必须同步开启数据库审计服务，并确保其能捕获
PREPARE/EXECUTE类预处理语句的完整参数值——否则你拦下了请求，却看不到真实 payload 长什么样，无法复盘绕过手法
最常被跳过的动作是：没把审计日志存到权限隔离的 OSS Bucket，导致 DBA 权限沦陷后，攻击者直接删掉本地审计表，整条取证链失效。
