一、SQL 注入为什么是 WAF 的「主场」
在所有 Web 攻击类型中，SQL 注入是 WAF 防护效果最好的一类。原因很直接：注入攻击必须携带特定的语法结构。
要成功注入，攻击者必须在参数中拼入 SQL 语句片段，这就必然留下痕迹：
- SQL 关键字（SELECT、UNION、WHERE 等）；
- 特殊符号组合（单引号、注释符、逻辑运算符）；
- 数据库特有的函数名与语法。
这些内容在正常业务参数中几乎不会出现。一个商品 ID 参数应该只包含数字，如果它出现了引号和 OR，那动机就很明显了。
二、四种检测机制
1. 特征规则匹配
最基础也最快的方式。规则库里预置了大量 SQL 注入的特征模式：
| 特征类型 | 示例特征 |
|---|---|
| 关键字组合 | 参数中出现查询语句关键词 |
| 注释符号 | 用于截断原语句的注释写法 |
| 逻辑恒真 | 用于绕过条件判断的表达式 |
| 联合查询 | 用于拼接查询结果的手法 |
| 延时函数 | 用于盲注的时间延迟函数 |
优点：检测速度快，资源消耗低。缺点：对编码变形、大小写混写、注释插空等混淆手法需要持续补充规则。
2. 语义分析
比规则匹配更进一层。它不只是「看有没有关键字」，而是尝试解析参数结构，判断是否构成合法的 SQL 语句。
这样做的好处是抗混淆能力强：攻击者把关键字拆开、编码、插注释，语义分析依然能还原出真实意图。但计算开销更大，对性能有一定要求。
3. 参数类型校验
最简单的思路，也是误报率最低的一种：如果参数理应是数字，那非数字内容就应该拒绝。
比如 /product?id=123，id 参数预期是整数。如果收到 id=123 AND 1=1，直接判定为非法参数。这种方式对特定参数非常有效，但需要知道每个参数的预期类型——通常通过自定义规则配置。
4. 行为异常检测
从「请求特征」转向「请求行为」。比如：
- 同一会话内大量返回数据库错误的请求；
- 短时间内尝试大量不同的注入载荷；
- 请求模式与正常业务明显不符。
这种方式能发现规则库还没覆盖的新型攻击，但需要一定的数据积累和建模能力。
三、为什么还有 SQL 注入能绕过 WAF
现实中确实存在绕过案例，常见原因有：
- 规则未覆盖新的注入手法——攻击技术与防护规则是持续对抗的关系；
- 业务本身允许特殊字符——比如富文本编辑器、SQL 教学网站，WAF 只能放宽规则，形成风险；
- 注入点不在 HTTP 参数里——比如通过 Cookie、Header、上传文件内容注入；
- 配置不当——为了减少误报关闭了核心规则。
所以正确的认知是：WAF 能拦住绝大多数 SQL 注入攻击，但它是「最后一道防线」而不是「唯一防线」。代码层的参数化查询才是根治手段。
四、站长该怎么配置
① 保持核心规则开启
SQL 注入防护规则属于核心规则，不要为了降低误报而关闭。如果确实有业务误拦，应该用白名单精确放行特定 URL 或参数，而不是全站关闭规则。
② 用自定义规则收紧高风险接口
对于明确知道参数类型的接口，用自定义规则做类型校验，效果比通用规则更好：
- 搜索接口的
page参数限定为数字； - 详情页的
id参数限定为数字或 UUID； - 排序参数限定为白名单枚举值。
③ 关注攻击日志
定期查看被拦截的注入尝试，能发现两件事：一是有没有人正在攻击你，二是攻击者盯上了哪个接口。后者对代码加固特别有价值。
④ 根治还是靠代码
WAF 是流量层防护，真正的修复在代码层：
- 使用参数化查询（预编译语句），从根本上杜绝拼接；
- 对所有外部输入做类型和格式校验；
- 数据库账号遵循最小权限原则（不要用 root 连业务库）；
- 关闭生产环境的详细错误回显，避免信息泄露。
五、小结
SQL 注入是 WAF 防护效果最确定的攻击类型，通过特征匹配、语义分析、类型校验、行为检测四层机制实现高准确率拦截。但 WAF 是流量层的兜底手段，代码层的参数化查询才是根治之道。两者结合，才能把 SQL 注入风险降到最低。
