WAF不是入漏万能的。这是洞何我在帮一家电商平台排查漏洞时得出的结论。他们的检测WAF规则库更新得比日历还勤，可攻击者还是防护用一条/*!50000union*/+select绕了过去——MySQL版本号注释，老掉牙的入漏手法，但规则库偏偏没覆盖。洞何

SQL注入的检测本质，是防护数据与代码的边界被打破。WAF站在两者之间，入漏像个门卫，洞何检查每个进出的检测参数。但门卫的防护麻烦在于，他只能看包络，入漏看不到业务逻辑。洞何攻击者构造畸形的检测HTTP请求，把payload拆成几段，用%00截断，用chunked编码分块传输，WAF的解析引擎一旦和Web服务器的解析器出现差异，就有缝可钻。

我亲眼见过一个案例：某政府网站的参数是id=1，WAF拦截了union关键字。攻击者改成id=1/*!50000union*/select，WAF没拦。为什么？因为WAF的正则匹配的是字面量union，而MySQL把注释内的内容当作可执行代码。规则库的编写者没考虑版本号注释这种语法糖，于是防线穿了。

检测防护的第一要务，不是堆规则，而是理解解析差异。你得知道你的WAF后面是什么：Apache还是Nginx？PHP还是Java？MySQL还是PostgreSQL？每种组合都有各自的解析怪癖。Nginx会把%u002f解码成/，但WAF如果按原始字节流检查，就看不到这层转换。攻击者利用这种“双重解码”问题，能轻松绕过基于签名的过滤。

换个思路，别只盯着请求。把响应也纳入检测范围。SQL注入成功的标志，是数据库的错误信息回显，或者页面内容出现异常。我认识一个安全工程师，他给WAF配置了响应体关键词监控——当页面返回mysql_fetch_array()或ORA-00933这类报错时，自动触发告警。这招对基于报错的注入特别有效，因为攻击者为了获取信息，必然要触发错误，而错误信息是藏不住的。

还有一个被忽视的检测点：请求频率和参数形态的关联分析。正常用户不会在十秒内对同一个接口发起三十次请求，每次的id值还带着sleep(5)这样的特征。WAF如果只做单包检测，就看不到这种时序模式。把流量日志拉出来做简单的统计，就能发现异常——但大多数WAF产品根本没做这个功能，它们更热衷于更新规则库。

规则库本身也有生命周期问题。SQL注入的手法在进化，从早期的' or 1=1--到现在的json_objectagg函数滥用，规则库的维护者永远在追赶。我做过一个实验：用ChatGPT生成一百种绕过WAF的payload，结果有三十七种能穿透某知名商业WAF的默认规则。不是WAF厂商不努力，是攻击面太宽，而签名匹配本质上是个黑名单游戏，黑名单总有漏网之鱼。

更务实的做法是分层防御。WAF放在最外层，拦截明显的扫描和批量攻击，保护后端不被打爆。真正的纵深防御，靠的是数据库层的参数化查询，靠的是ORM框架的预编译语句。WAF防不住order by后的注入点——因为那里根本不能参数化，只能白名单校验字段名。你得承认WAF的局限性，把它当作减速带，而非防火墙。

最后说个实战技巧：在WAF的日志里搜索400状态码和403响应，那些被拦截的请求往往藏着攻击者的试探痕迹。分析这些日志，你能发现新的绕过模式，反哺规则库。有个同事靠这个办法，在日志里发现了一串base64编码的payload，解码后是UNION ALL SELECT NULL,NULL,NULL——攻击者在测试列数，WAF拦住了，但规则库里没有对应的告警规则，差点漏报。

WAF不是摆设，但也别神话它。它是个需要持续调优的工具，是个会漏报误报的过滤器。真正有效的防护，是理解攻击者的思路，承认解析差异的存在，把检测维度拉长到请求和响应两侧。规则库要更新，但更要更新的是你对WAF局限性的认知。