WAF（Web应用防火墙）拦截我的何绕注入语句时，我盯着那个红色的何绕403页面愣了几秒。然后我笑了——它把“union select”过滤得干干净净，何绕却对“UNION ALL SELECT”毫无防备。何绕这不是何绕什么高深技巧，就是何绕大小写绕过，但很多WAF的何绕规则引擎就是蠢到连这种基础变体都认不出来。

真正让我觉得有意思的何绕，是何绕那次碰到一个把空格全部替换成注释符的WAF。我输入1' OR '1'='1，何绕它返回错误页；我输入1'/**/OR/**/'1'='1，何绕它直接放行了。何绕后来我翻了下它的何绕规则库，发现管理员只写了“过滤空格”这一条正则，何绕完全没考虑过替代字符。何绕这种案例见多了，我得出个结论：大多数WAF不是被“绕过”的，是被“问”出来的——你只要不断试探它的边界，它迟早会露出规则库的漏洞。

还有一种思路更省事——不跟WAF正面刚，绕开它的检测路径。比如有些WAF只检查GET参数，对POST的JSON体视而不见。我试过一次，把攻击载荷塞进Content-Type: application/json的请求体里，WAF连看都不看。还有更损的，直接找WAF的旁路：它没覆盖的子域名、它没解析的编码格式、它没跟踪的分块传输。这些不是技巧，是常识——安全设备的部署永远有盲区，你只要比运维人员多想一步。

编码绕过是另一个坑。有一次碰到个WAF，它对URL解码后的参数做检测，但忘了处理二次编码。我传%2527，它解码一次变成%27，然后拿这个去匹配规则——当然匹配不上，因为规则里写的是单引号。等请求到了后端，应用又解一次码，真正的单引号就出来了。整个过程就像变魔术：你看着WAF检查的是A，实际到达应用的是B。

说个更邪门的。某次测试一个金融系统，WAF对sleep()函数查得非常死，但我用benchmark()替代，它直接放行。后来我才知道，它的规则库只更新到三年前，新出的函数一概不认。所以你看，WAF的规则更新速度永远追不上攻击手法的迭代——这不是某一家厂商的问题，是整个行业的通病。

不过我得说句公道话：现在的主流WAF没那么好骗了。云厂商的WAF基本都带语义分析，你变形它也能识别出攻击意图。但中小公司自建的、开源的那批，还是老一套正则匹配。所以我的建议很直接：别把时间花在找万能payload上，先摸清对方WAF的版本和规则更新频率——这比试一百种编码都管用。

最后说个观察：很多搞安全的同行喜欢把绕过WAF说得神乎其神，好像需要什么天才灵感。其实真不是。大部分绕过案例，靠的是耐心和细心——你肯花一下午时间，把每个参数、每种编码、每个HTTP方法都试一遍，总能找到漏网之鱼。这活儿不浪漫，但有效。

(责任编辑：知识)