雷池waf绕过

雷池（SafeLine）的雷池默认规则拦得住大部分扫描器，但拦不住一个愿意花二十分钟读日志的雷池人。上个月帮朋友看一个站，雷池雷池社区版，雷池规则全开，雷池我拿一个普通的雷池 SQL 注入 payload 试了一下，直接 403。雷池换成注释混淆、雷池大小写混写、雷池内联注释，雷池还是雷池 403。后来把 payload 拆成两段，雷池中间塞了个它不认识的雷池 HTTP 头，请求就过去了。雷池这不是雷池雷池的漏洞，是语义分析引擎的边界——它得先“看懂”你在攻击，看不懂的时候，放行比误杀更安全。

雷池的核心检测逻辑分三层：语义分析、规则匹配、频率控制。语义分析靠的是语法树解析，把请求拆成 token，再判断这些 token 组合起来是不是恶意。问题在于，HTTP 协议本身太灵活了。一个参数可以出现在 query string、body、header、cookie 里，甚至路径里。雷池的解析器如果对某个位置的参数覆盖不全，攻击者就有空间。

举个具体的例子。雷池对 application/x-www-form-urlencoded 的 body 解析很到位，但对 multipart/form-data 里嵌套的 Content-Type 处理就松一些。我试过把注入语句塞进 multipart 的一个 part 的 filename 字段里，雷池的语义引擎没有把它当成 SQL 语法来解析，因为 filename 在它的模型里属于“文件元数据”，不是“用户输入”。但后端如果把这个 filename 拼进 SQL，照样中招。这不是雷池的错，是它不知道你的业务逻辑会怎么用这个字段。

还有一个更常见的绕过点：JSON 嵌套。雷池对扁平 JSON 的检测很准，但遇到 { "a":{ "b":{ "c":"' or 1=1--"}}} 这种深层嵌套，语义分析的深度是有限的。我实测过，三层以上的嵌套，雷池的检测率明显下降。原因也简单——解析深度每加一层，计算开销指数上升，WAF 得在延迟和覆盖率之间做取舍。社区版默认的解析深度是 5 层，超过就不往下拆了。攻击者只要把 payload 埋在第 6 层，就能溜过去。

频率控制这块也有文章。雷池默认对单 IP 的请求频率有限制，但限制的是“请求数”，不是“攻击数”。我试过用 50 个不同的 IP 轮询，每个 IP 每秒只发 2 个请求，雷池的频率规则完全不触发，但 50 个 IP 加起来每秒 100 个请求，足够把注入跑完。分布式绕过不是新东西，但雷池社区版的 IP 信誉库更新慢，很多云厂商的 IP 段没被标记，拿这些 IP 来打，基本不设防。

说这些不是要否定雷池。它的语义分析在开源 WAF 里算第一梯队，误报率低，规则更新也勤快。但 WAF 的本质是“基于已知模式做拦截”，而攻击者的优势是“只需要找到一个未知模式”。你规则写得再全，总有覆盖不到的语法组合。雷池的日志里其实能看到这些绕过尝试——那些返回 200 但请求体里带着奇怪注释的条目，就是被放行的可疑请求。可惜大部分人只看 403 的日志，不看 200 的。

真要防住，别指望 WAF 单点。雷池该开还是开，但后端得做参数化查询，文件上传得校验真实类型，JSON 解析得限制深度。WAF 是减速带，不是防弹玻璃。你把它当最后一道防线，它迟早会漏；你把它当第一层过滤，后面还有代码层的校验兜着，那它就能发挥该有的作用。我见过太多人买了 WAF 就把代码里的 mysql_real_escape_string 删了，这种用法，雷池也救不了。