文章总结： 一篇2026年3月发表在ACSAC的论文提出名为Waffled的方法，通过利用WAF与后端应用对HTTP请求结构的解析差异，在不修改恶意payload本身的情况下，成功在AWSWAF、AzureWAF、GoogleCloudArmor、CloudflareWAF和ModSecurity五款主流WAF上验证了1207个独特的绕过向量。攻击手法集中在HTTP协议层的结构、元数据和格式层面，如构造畸形的multipart/form-data边界、JSONContent-Type头或XMLDOCTYPE，导致WAF因无法理解而放行请求，而后端框架则能正常解析并执行payload。研究指出超过90%的网站同时接受多种Content-Type格式，加剧了此风险。短期防御建议升级OWASPCRS规则集并禁用非必要Content-Type，长期可部署HTTP规范化工具消除解析差异。 综合评分： 88 文章分类： web安全,漏洞分析,渗透测试,安全运营,解决方案

别怪Payload太狠：WAFFLED用1207个绕过告诉你，五款主流WAF的解析逻辑全是筛子

原创

逍遥 逍遥

昆仑AI安全实验室

2026年5月5日 01:12 广东

在小说阅读器读本章

去阅读

2026年3月，一篇发表在ACSAC上的论文引发安全界震动。来自东北大学和达特茅斯学院的研究团队，用一种叫WAFFLED的方法，在AWS WAF、Azure WAF、Google Cloud Armor、Cloudflare WAF和ModSecurity这五款全球主流WAF上，验证了1207个独特的绕过向量——每个向量对应一种让WAF把恶意请求当成合法流量的手法。

更惊悚的是：超过90%的生产环境网站，同时接受application/x-www-form-urlencoded和multipart/form-data两种格式的请求。换句话说，WAFFLED这套手法可以打穿绝大多数Web应用。

这不是漏洞，是WAF与后端应用之间的根本性架构缺陷。

传统WAF绕过的套路，已经不够用了

过去二十年，绕过WAF的思路集中在Payload本身：SQL注入加注释、XSS编Base64、RCE套双层引号。攻击者不断往恶意Payload里塞混淆字符，让它骗过WAF的规则匹配，同时保持对后端应用的可执行性。

但这条路越来越窄。WAF厂商已经把已知的编码、混淆、变形套路全写进了规则库，OWASP Core Rule Set也覆盖了绝大多数传统绕过。2026年的WAF，你再用vuln=1' OR '1'='1' -- -这种Payload去打，十个有九个拦得死死的。

WAFFLED的思路，完全换了一个方向。

它不碰Payload。Payload是干净的、标准的、不包含任何可疑字符的——就是一个<script>alert(1)</script>，或者一个' OR '1'='1。WAFFLED动的手脚在别的地方：HTTP请求的结构层、元数据层、格式层。

把multipart/form-data的分隔边界拆开用RFC 2231参数延续重构；在JSON请求头里塞一个不规范的charset字段；在XML的DOCTYPE里插入一个从未见过的命名空间。这些变化对后端框架来说完全合法——Flask、Express、Spring Boot该怎么解析还怎么解析。但对WAF来说，这变成了一个它看不懂的请求体结构。

WAF看到的是一个畸形的、混乱的、结构异常的请求，但它又不能直接拦截——因为生产环境里确实存在大量不严格遵循RFC规范的合法流量。所以WAF的选择是：跳过这个它看不懂的请求，放行给后端处理。而后端框架正常解析，恶意Payload执行。

这就是解析差异攻击的本质：WAF理解的和后端理解的，不是同一个HTTP请求。

“四叉戟”攻击模型：不碰Payload，只打结构

WAFFLED的可复用方法论里定义了四个攻击面：“header”、“preamble”、“epilogue”、“part”。分别对应HTTP头、multipart分隔声明、multipart结束段、以及每个multipart部件本身。

传统fuzzer只盯着参数值去改，WAFFLED的fuzzer盯的是结构。下面用三个典型的攻击手法来说明这一点。

第一个手法打multipart/form-data。正常的multipart请求以空行（CRLF CRLF）标记每个部件内容的开始，空行后面是原始内容。WAFFLED在空行位置插入一个无意义的额外头（比如X-Ignore: x），再在不同位置插入\x00空字节。WAF的multipart解析器在遇到\x00时认为结构已损坏，放弃解析后续内容。Flask和Express的parser直接跳过\x00和多余的头，找到真正的空行后继续解析，正常提取Payload。典型绕过向量之一：在两个boundary之间插入Content-Disposition: form-data; name="safe"和一个无害值，WAF以为这是完整请求，后端继续读后面的真正攻击部件。

第二个手法打JSON Content-Type头。攻击者发送Content-Type: application/json; charset=utf-8; boundary=evil这种畸形头。WAF的Content-Type解析器在遇到charset参数时停止继续解析后续的boundary参数，把请求当作普通JSON处理。后端框架看到boundary=evil，按multipart逻辑处理，Payload以multipart部件形式隐藏在真正的boundary声明之后。最终效果是WAF只看到了无害的JSON body，后端执行了隐藏在multipart部件里的攻击。

第三个手法打XML。利用XML的不同解析模式。WAF通常使用“特性驱动解析”——它先识别<script标签和onerror属性，判定为恶意。但XML还支持一种叫DOCTYPE内部子集的声明方式。攻击者用参数实体引用把<script拆成片段：<!ENTITY % a "<sc"><!ENTITY % b "ript>">，再在XML body中通过%a;%b;重组。WAF在解析时无法追踪参数实体的展开，只看到一堆无害的ENTITY声明，把请求放行。Spring和ASP.NET的XML解析器在运行时自动展开参数实体，完整的<script>alert(1)</script>被执行。一种利用了XML命名空间差异的手法，直接让Azure和Cloud Armor的WAF把onclick=alert(1)当成了合法XML属性。

这四类攻击手法的共同特征是：Payload本身不包含任何混淆、编码、变体。就是一个标准的攻击语句。WAFFLED做的事，是在HTTP协议层创造WAF与后端之间的理解偏差。

五款主流WAF，全被打穿

AWS WAF、Azure WAF、Google Cloud Armor、Cloudflare WAF、ModSecurity——WAFFLED的1207个绕过向量覆盖了全部五款产品。其中Cloudflare WAF和ModSecurity被利用畸形的multipart边界声明打穿；Azure WAF和Google Cloud Armor在JSON Content-Type头的解析上被绕过；Google Cloud Armor单例接受了30个恶意请求，并直接联系研究团队要求获取测试包以进行内部复现；Cloudflare和微软则在其透明漏洞披露框架中对发现予以认可并推动修复。

值得注意的是，AWS WAF是唯一没有被击穿的产品。它的parser比其他几家更严格，更贴近RFC标准。代价是性能——严格的解析需要更多CPU时间和内存开销。这揭示了一个结构性困境：WAF厂商在“拦截率”和“性能”之间做取舍时，往往选择了性能优先的宽松解析策略。

而攻击者就是利用了这个取舍。

不止WAFFLED。2026年1月，安全团队FearsOff发现Cloudflare的ACME证书验证路径/.well-known/acme-challenge/完全绕过了所有WAF规则——不管你的WAF策略写得有多严，指向这个路径的请求一律直接转发到源站。漏洞根源是Cloudflare的逻辑设计缺陷：当它为自己管理的证书订单提供挑战令牌时，会临时禁用WAF规则。但当一个请求的令牌与Cloudflare管理的证书不匹配时，WAF并未重新启用，请求直接裸奔到源站。这个漏洞已在2025年10月修复。

2026年4月，OWASP CRS的核心规则被爆存在变种绕过（CVE-2026-21876）。规则922110校验multipart部件的Content-Type头中的charset值，只检查循环结束后的最终状态。攻击者只需在最后一个multipart部件里放一个合法的charset值，前面的所有部件里仍可以携带恶意payload。

为什么大多数网站都在裸奔

WAFFLED团队做了一项很有意思的实网调研。

他们用PublicWWW扫描了100个热门网站的“忘记密码”页面。结果发现：超过90%的网站同时接受application/x-www-form-urlencoded和multipart/form-data两种格式的请求。四分之一网站已经在使用JSON作为请求体格式。

这意味着什么？意味着攻击者根本不需要精心寻找目标。拿到任何一个网站，把Content-Type从x-www-form-urlencoded直接切成multipart/form-data，后端照样认；把Content-Type切成application/json，四分之一的网站照样认。但WAF在这两三种不同的解析模式下，会表现出完全不同的语法理解偏差。

这是WAFFLED这套手法能有如此高成功率的根本原因：不是攻击者找到了某个特定WAF的漏洞，而是HTTP协议的灵活性与WAF解析严格性之间存在系统性鸿沟。后端框架为兼容性做了大量的容错处理，而WAF没有能力模拟每一种框架的容错逻辑。

面对WAFFLED，至少做好这几件事

短期补丁：升级OWASP CRS到4.22.0或3.3.8以上版本。开启Azure DRS 2.1规则集。Cloudflare的ACME路径逻辑已修复。没有立刻升级条件的，可以在业务不需要的场景下禁用非必要的Content-Type格式——如果你的API只接受JSON，直接在WAF层配置只允许application/json，拒绝所有multipart和XML。

长期防御：研究团队开发了一个叫HTTP-Normalizer的开源代理工具。它的工作方式很直接：对每一个经过的HTTP请求，用严格遵循RFC标准的ABNF语法解析器重新解析一遍。不符合标准的请求直接拒绝，不往下传。因为WAF和后端收到的都是同一个“规范化”后的请求，不存在解析差异的可能性。初步测试中，HTTP-Normalizer能够在不引入显著延迟的情况下，让100%的WAFFLED攻击样本被规范化或阻断。

另外，禁止随意切换Content-Type。应用层对非预期Content-Type不响应，在WAF层开启严格协议校验，在核心业务接口处部署定制的Parser插件。

WAFFLED最大的贡献，不是发现了某个WAF的漏洞，而是验证了一个原则：

WAF和后端应用对同一个HTTP请求是否理解一致，才是安全的第一道关口。一致性比规则库更重要。

当你花了预算买了一款大牌WAF，上线了最严格的规则集，但你的后端框架对multipart边界声明的容错策略，和WAF的容错策略不一样——那你的安全防线，就只是一层塑料薄膜。你花大价钱买的规则集，压根没看到那个请求。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：昆仑AI安全实验室 逍遥 逍遥《别怪Payload太狠：WAFFLED用1207个绕过告诉你，五款主流WAF的解析逻辑全是筛子》