去年帮一个朋友看他的过技电商站，日志里一堆请求长得像这样：/product?过技id=1%20union%20select%201,2,3--。WAF 日志标了"拦截"，过技但数据库慢查询里明明有对应的过技执行记录。他问我是过技不是 WAF 坏了。没坏，过技是过技绕过发生了。
WAF 绕过的过技本质不是"攻破"防火墙，而是过技让 WAF 和它后面那台服务器对同一个请求产生不同的理解。只要两者解析结果不一致，过技中间就有缝。过技
大小写与注释：最老但还活着
早期 WAF 用正则匹配 union select，过技攻击者写 UnIoN SeLeCt 就过去了。过技现在的过技 WAF 大多做了大小写归一化，但注释符插空依然有效：union/**/select。过技MySQL 把 /**/ 当注释，WAF 的正则如果没处理注释，就匹配不到连续关键字。我在一次内部测试里用 /*!50000union*/ 直接穿过了某商业 WAF 的默认规则集——MySQL 会执行版本号大于 50000 的注释内语句，WAF 却把它当普通注释忽略。
编码：WAF 解码几次，服务器解码几次
这是最有意思的一块。WAF 通常会对 URL 做一次解码再检测，服务器可能做两次。你发 %2527，WAF 解一次得到 %27，看起来人畜无害；服务器再解一次变成 '，单引号就进去了。宽字节注入是同一逻辑的变体：%df%27，GBK 编码下 %df%5c 合成一个汉字，把转义用的反斜杠吃掉，单引号逃逸。这类绕过不靠猜规则，靠的是搞清楚两边解码链的差异。
分块传输：把 payload 切碎
HTTP/1.1 的 Transfer-Encoding: chunked 允许把请求体拆成多个块。WAF 如果只检测第一个块或不做重组，攻击者把 union select 拆到两个 chunk 里，WAF 看到的是两段无害片段，后端拼起来才是完整语句。2019 年那波针对云 WAF 的 chunked 绕过就是靠这个，很多厂商连夜补丁。分块大小还能塞垃圾数据干扰，比如每块前面加一堆 0。
参数污染：HPP 的经典玩法
同一个参数名传两次：?id=1&id=union select。WAF 取第一个值 1，判定安全；PHP 的 $_GET 默认取最后一个，拿到注入语句。ASP.NET 可能拼接成 1,union select。不同语言、不同框架取值策略不一样，WAF 和业务代码各取各的，缝隙就出来了。我见过一个案例，WAF 检测 id 参数时用了 getParameter 拿首值，后端用了 getParameterValues 拿全部再拼接，直接绕过。
协议层与架构层
有些 WAF 部署在反向代理后面，只认 X-Forwarded-For 做 IP 白名单。攻击者伪造这个头，声称自己来自内网，WAF 直接放行。还有的 WAF 对 Content-Type: multipart/form-data 的解析和 PHP 不一致，边界字符串构造得刁钻一点，WAF 解析失败就跳过检测。这类绕过不碰 payload 本身，打的是 WAF 的信任假设。
我的判断
WAF 绕过不是玄学，是协议解析差异的工程问题。防御方要做的不是堆规则，而是保证 WAF 和业务服务器用同一套解析逻辑，或者干脆在 WAF 层做归一化后再检测。攻击方要做的，就是找到那个"两边理解不一样"的点。这个博弈会一直持续，因为 HTTP 协议本身留了太多解释空间。