生产环境必须将WAF SQL注入防护从默认“观察模式”手动改为“拦截模式”，并开启JSON解析、强化高危路径规则、分离审计日志、严格限制数据库端口仅内网访问，且确保各系统NTP时间同步。
生产环境不开启 SQL 注入检测，等于把数据库的 WHERE 条件直接暴露给攻击者——' OR 1=1 -- 这类载荷只要发出去，就可能绕过登录、拖走用户表、甚至执行 SELECT @@version 确认数据库类型后发起提权。
WAF 的 SQL 注入规则默认是“观察模式”，不是“拦截模式”
阿里云 WAF 控制台里，Web 核心防护规则 中的 SQL 注入子项，默认动作是 观察。这意味着所有匹配到 UNION SELECT、EXEC xp_cmdshell、十六进制编码的 0x554e494f4e（即 UNION）等特征的请求，只会记录日志，不会阻断。
真实场景中，你看到控制台“SQL 注入防护已开启”，但其实它只是在记账，没关门。
必须手动操作：
- 进入 WAF 控制台 →
Web 攻击防护→SQL 注入 - 将动作从
观察改为拦截 - 特别注意：高危路径如
/login、/api/v1/search、/order/query建议单独加白名单或强化规则等级
POST 请求带 JSON body 时，WAF 默认不解析，会漏掉注入
前端用 fetch 或 axios 发送 {"username":"admin'--"} 这种 payload，如果 WAF 没开 JSON 解析，就只看到原始字节流，无法提取 key-value 做语义分析，SecRule ARGS:username "@rx '.*?--" 类规则根本不会触发。
检查并开启：
- WAF 控制台 →
防护配置→Web 核心防护→JSON 解析开关必须为开启状态 - 该开关影响所有 POST/PUT 请求体中的 JSON 数据，不开启 = 对 API 接口形同虚设
- 若业务同时用 form-data 和 JSON，需确认 WAF 规则组是否覆盖
Content-Type: application/json场景
审计日志和 WAF 日志必须分离，且不能由 DBA 可删
WAF 拦住了攻击，但如果你没配好数据库审计服务，就等于只抓了小偷进门的动作，却不知道他进了哪个房间、拿了什么、有没有留下后门。
常见错误配置：
- 把
Database Audit ServiceAgent 装在和 RDS 同一台 ECS 上 - 审计日志写进同一个 RDS 实例的
mysql.audit_log表 - OSS Bucket 的 RAM Policy 允许
DBA角色执行DeleteObject
正确做法是：
- 启用独立的云厂商审计服务（如阿里云
Database Audit Service），走镜像流量采集 - 审计策略中必须勾选
PREPARE/EXECUTE语句的完整参数记录，否则看不到SET @p = 'admin''--'; EXECUTE stmt USING @p的真实值 - 日志目标 OSS Bucket 的权限策略中，显式拒绝
DBA组的oss:DeleteObject和oss:PutBucketPolicy
云防火墙必须限制数据库端口仅内网访问
即使 WAF + 参数化查询全开了，只要 MySQL 的 3306 端口暴露在公网，攻击者就能绕过所有应用层防护，直连数据库尝试暴力破解或利用 CVE-2023-21912 这类认证绕过漏洞。
这不是“多此一举”，而是边界防御的刚性要求：
- 在阿里云
云防火墙 CFW控制台，新建访问控制策略 - 源地址设为
any，目的端口填3306，动作设为拒绝 - 再加一条放行策略：源地址为业务 ECS 的内网 IP 段，目的端口
3306，动作允许 - 检查 RDS 实例的白名单，确保未开放
0.0.0.0/0
真正容易被忽略的是时间同步——WAF 日志、数据库审计日志、云防火墙日志如果 NTP 不统一，关联分析时根本对不上时间戳，查入侵链路会卡在“谁先干的、谁后干的”这种基础问题上。
