WAF防火墙配置防止SQL注入实操指南

WAF对SQL注入的拦截能力并不取决于设备品牌，而取决于规则是否贴合业务参数结构。多数WAF默认规则集对联合查询、报错注入、时间盲注的识别率很高，但遇到参数被编码、注释符穿插、数据库特性函数变形时，漏报率会明显上升。真正有效的配置思路是：先梳理业务接口的输入特征，再针对参数位置、提交方式、编码类型建立白名单基线，最后用自定义规则补足通用规则的盲区。

透明桥接模式下WAF能看到完整的HTTP请求和响应，检测能力最强，但无法处理HTTPS加密流量，除非做SSL卸载。反向代理模式可以解密HTTPS，是当前主流部署方式，但需要确保后端服务器只接受来自WAF的流量，否则攻击者可以直接绕过WAF访问源站。旁路镜像模式只能告警不能阻断，不适合作为SQL注入防护的唯一手段。如果你的业务强制使用TLS 1.3，必须确认WAF支持对应的SSL卸载和证书管理能力，否则SQL注入检测会直接失效。

很多管理员把WAF自带的全部规则集打开，结果误报率飙升，业务接口频繁被拦截，最后只能把WAF调成检测模式或者对整站加白。SQL注入防护的核心规则应该集中在几类：SQL关键字匹配、危险函数调用、注释符利用、元数据查询、布尔/时间盲注特征。像“检测通用SQL注入”“检测SQL注释”“检测UNION SELECT”这类规则必须开启，但“检测所有包含单引号的请求”这种过于宽泛的规则要谨慎，它会误伤正常的文本输入。建议先开启OWASP SQL注入相关规则组，观察一周误报情况，再逐条调整。

对于已经上线的业务系统，最有效的做法是梳理所有接口的参数名、参数类型、允许的字符集和长度范围。例如登录接口的用户名字段只允许字母数字下划线，长度6到20位；搜索接口的关键词字段允许中文、字母、数字和空格，长度不超过50；分页参数page必须是1到9999的整数。把这些规则写入WAF的自定义策略，命中白名单的参数直接放行，不在白名单内的参数再进入SQL注入检测流程。这样既能降低误报，又能把检测资源集中在真正需要防护的输入点上。对于无法逐一梳理的老系统，至少要对所有携带SQL关键字的参数值进行阻断，并对参数值中出现分号、注释符、UNION、SELECT、SLEEP、BENCHMARK等特征的情况直接拦截。

攻击者常用URL编码、双重URL编码、十六进制编码、Unicode编码来绕过WAF的关键字匹配。例如把SELECT编码成%53%45%4C%45%43%54，或者用MySQL的CONCAT(0x53,0x45,0x4c,0x45,0x43,0x54)来拼接关键字。WAF需要开启递归解码功能，至少支持URL解码、HTML实体解码和Base64解码，并且解码深度建议设置为3层以上。同时要开启对请求体中JSON、XML格式数据的解析检测，很多注入发生在JSON字段里，而默认规则只检查URL参数和表单参数。对于Content-Type为application/json的请求，WAF必须解析JSON结构并逐个检查字符串值。

MySQL支持多种注释方式，包括#、-- 、/* */，以及内联注释/*! */。攻击者常用这些注释来拆分SQL关键字，例如UN//ION SEL//ECT。通用规则可能无法覆盖所有注释变体，建议添加自定义正则规则。以下是一个针对MySQL注释绕过的检测规则示例：

# 检测请求参数值中包含SQL关键字与注释符混合的情况
# 匹配模式：关键字中间插入注释、空白或特殊字符
pattern: (?i)(union[\s/*!]+select|select[\s/*!]+from|or[\s/*!]+1[\s/*!]*=|and[\s/*!]+1[\s/*!]*=|sleep[\s/*!]*\(|benchmark[\s/*!]*\()
action: block

这条规则能拦截union select、select from、or 1=1、and 1=1、sleep()、benchmark()等常见注入模式，即使中间插入了注释符或多余空白。对于MSSQL环境，还需要增加对exec、xp_cmdshell、information_schema等关键字的检测。对于Oracle环境，要关注utl_http、dbms_pipe等包的使用。

时间盲注的特征是请求响应时间异常变长，但请求内容本身可能不包含明显的SQL关键字。攻击者使用SLEEP(5)、pg_sleep(5)、WAITFOR DELAY等函数让数据库暂停响应。WAF的通用规则可以检测这些函数名，但如果攻击者使用BENCHMARK(50000000,MD5(1))这种计算密集型操作来制造延迟，关键字匹配可能失效。建议在WAF上配置响应时间阈值告警，例如同一源IP在短时间内多个请求的响应时间超过3秒，触发临时封禁。同时开启对SLEEP、BENCHMARK、pg_sleep、WAITFOR等函数的严格检测，即使出现在编码后的参数值中也要拦截。

布尔盲注的请求参数值通常包含AND、OR、=、>、<等逻辑运算符，并且攻击者会反复发送只有条件值不同的请求来比对响应差异。WAF需要检测参数值中是否出现逻辑运算符与数字、字符串的组合，例如and 1=1、and 'a'='a'、or 2>1。同时要开启基于频率的检测，同一参数在短时间内被提交多次且参数值只有细微变化，应触发告警或阻断。对于返回页面长度差异明显的请求，可以配置WAF学习正常响应的长度范围，发现异常波动时进行拦截。

搜索接口是SQL注入的高发区，因为搜索词会被拼接到LIKE、IN、WHERE等SQL语句中。除了常规的关键字检测，还需要对搜索参数中的通配符进行限制，例如%和_在MySQL中具有特殊含义，攻击者可以利用它们进行模糊匹配探测。建议在WAF上对搜索参数设置独立的字符白名单，只允许中文、字母、数字、空格和少量标点。文件上传接口虽然不直接执行SQL，但上传的文件名、文件内容中的元数据可能被后端程序写入数据库，如果文件名包含SQL注入payload，同样会造成危害。WAF需要对multipart/form-data请求中的filename字段进行严格检测，禁止包含SQL关键字、单引号、分号等字符。

配置完WAF规则后，必须开启完整的攻击日志记录，包括请求时间、源IP、目标URL、参数名、参数值、命中的规则ID、执行动作。每天检查日志中被拦截的SQL注入请求，分析攻击者的payload特征，判断是否有绕过尝试。如果发现某个参数频繁触发规则但业务正常，需要调整规则或添加白名单。如果发现某个接口的注入尝试从未被拦截，要立即补充自定义规则。建议每周导出一份SQL注入拦截报告，统计攻击来源、攻击类型、目标接口分布，根据数据变化调整防护策略。

WAF的SQL注入防护本质上是基于特征匹配和异常检测的补偿措施，无法覆盖所有绕过手法。攻击者可以使用WAF未收录的数据库函数、利用类型转换、使用等价字符替换等方式绕过检测。真正解决SQL注入问题需要在代码层面使用参数化查询或预编译语句，对所有输入进行严格的类型校验和长度限制。WAF的作用是在代码修复完成前提供临时防护，以及在代码修复后作为纵深防御的一层。如果业务系统存在大量SQL注入漏洞，仅靠WAF防护是不可持续的，必须推动开发团队尽快修复。

第一个误区是把WAF当成IPS来用，开启所有攻击检测功能，导致性能下降和误报增加。第二个误区是只检测GET参数，忽略POST请求体、Cookie、HTTP头中的注入点。第三个误区是配置完成后不做测试，直接用真实攻击流量验证才能发现规则是否生效。第四个误区是过度依赖WAF的默认规则，不根据业务特点做定制化调整。第五个误区是WAF规则更新不及时，新型注入手法出现后没有及时同步规则库。第六个误区是把WAF部署在源站同一台服务器上，攻击者一旦拿到服务器权限就可以直接关闭WAF。

配置完成后，使用手工构造的payload进行测试。先测试最基础的注入：在参数值中输入单引号，观察WAF是否拦截。再测试联合查询：输入union select 1,2,3，观察拦截情况。然后测试注释绕过：输入union//select，观察是否被拦截。接着测试编码绕过：把payload进行URL编码后提交，观察WAF是否解码检测。最后测试时间盲注：输入sleep(5)或benchmark(10000000,md5(1))，观察请求是否被拦截以及响应时间是否异常。如果以上测试都能被有效拦截，说明WAF的SQL注入防护配置基本到位。如果某个测试绕过成功，需要针对性地补充规则。

WAF的SQL注入防护配置是一个持续优化的过程，不是一次性工作。业务接口会变化，攻击手法会升级，WAF规则也需要定期回顾和调整。把参数白名单基线建立好，把自定义规则维护好，把日志监控执行好，WAF才能真正成为SQL注入防护的有效屏障。