文章总结： 本文剖析了Cloudflare因ACME协议校验缺陷导致的高危WAF绕过漏洞。攻击者利用合法Token欺骗禁用WAF规则直连源站，根源在于未校验Token归属。建议架构设计时强化上下文隔离与纵深防御，严格审计业务白名单逻辑，避免此类后门风险。 综合评分： 90 文章分类： 漏洞分析,WEB安全,云安全

深度复盘：如何用一个合法的 Token，穿透 Cloudflare 的铜墙铁壁？

原创

Hankzheng Hankzheng

技术修道场

2026年1月27日 07:59 广东

导读： 为了业务便利性而设置的“白名单”机制，如果校验逻辑不够严谨，往往会成为安全防线上的致命“后门”。本文将深入剖析 Cloudflare 刚刚修复的一个高危逻辑漏洞。

大家好，做运维或者搞网络安全的兄弟们，对 Cloudflare（CF） 肯定不陌生。作为全球顶级的云安全服务商，它的 WAF（Web应用防火墙）一直是我们心中阻挡恶意流量的“叹息之墙”。

但是，如果我告诉你，只要利用 SSL 证书续签协议里的一个小机制，就能绕过这堵墙，直接访问你的源站（Origin Server），是不是觉得后背发凉？

最近，Cloudflare 官方披露并修复了一个高危逻辑漏洞。这个漏洞非常有意思，它不是因为代码写得烂，而是因为业务逻辑考虑得“太贴心”了。

今天，咱们就扒开揉碎了，来看看他是怎么实现的，以及我们能从中学到什么。

01 基础知识：ACME 协议与 HTTP-01 挑战

在讲漏洞之前，咱们得先复习一下 ACME 协议（RFC 8555）。

现在的网站基本上都上了 HTTPS，为了省事，大家都会用 Certbot 这类工具来自动申请和续签证书（比如 Let’s Encrypt）。这个自动化的过程，就是基于 ACME 协议的。

CA 机构（发证书的）需要确认“这域名真是你的”，最常用的方法就是 HTTP-01 Challenge。

简单来说，流程是这样的：

• CA 说

  “你在你服务器上放一个文件，路径是 /.well-known/acme-challenge/<TOKEN>，内容是特定的指纹。”

• 你（客户端）

  照做，把文件放好。

• CA 的服务器

  发起一个 HTTP GET 请求去访问这个 URL。

• 验证

  如果能读到且内容正确，域名验证通过，下发证书。

看起来天衣无缝，对吧？问题就出在 Cloudflare 这种“中间人”身上。

02 那个“好心办坏事”的逻辑

当你的网站接入 Cloudflare 后，所有的流量都会先经过 CF 的边缘节点。

这里存在两种情况：

1. CF 帮你管理证书

   CF 直接拦截这个 ACME 请求，自己替你回答 CA，完成验证。

2. 你自己管理证书

   CF 发现这不是它发起的订单，就把请求转发回你的源站（Customer Origin），让你的服务器去响应。

重点来了！👇

WAF 的职责是拦截异常流量。但是，CA 机构过来验证的请求，通常是一堆自动化脚本，长得特别像“爬虫”或者“恶意扫描”。如果不做处理，WAF 很容易把 CA 的验证请求给拦截了，导致证书续签失败。

为了防止这种“误杀”，Cloudflare 的工程师写了一段逻辑：

“如果请求的路径是 /.well-known/acme-challenge/*，且 Token 看起来是有效的，那咱们就别让 WAF 介入了，直接放行吧！”

这个初衷是好的：为了业务的稳定性，牺牲一点点特定路径的安全性。 毕竟那个路径只是个验证文件嘛。

03 漏洞复盘：移花接木的艺术

但是，安全圈有句老话：所有的白名单，都是潜在的后门。

安全研究员 FearsOff 发现，Cloudflare 在判断“Token 是否有效”时，犯了一个严重的上下文逻辑错误。

之前的有缺陷逻辑是这样的：

1. 用户发起请求：GET https://target.com/.well-known/acme-challenge/<TOKEN>
2. CF 检查： 是否存在于 CF 的全球系统中？（注意：它只检查了 Token 是否存在，没严格检查这个 Token 属于哪个域名！）
3. 如果 Token 存在（哪怕是属于攻击者自己域名的）：CF 禁用 WAF。
4. CF 继续检查：这个 Token 是属于 target.com 的吗？
5. 发现不匹配（因为 Token 是攻击者的）：CF 认为这不是自己该处理的订单，于是把请求透传给 target.com 的源站。

你看懂这个操作了吗？

攻击者可以先给自己控制的域名申请一个 ACME Token。然后，拿着这个合法的 Token，去访问受害者域名的 ACME 路径。

此时，Cloudflare 的边缘节点一看：“哟，这 Token 我认识，是有效的（虽然不是这家的），为了防止误杀 CA，先把 WAF 关了吧。”

然后，因为 Token 和域名不匹配，CF 并没有拦截响应，而是把请求转发给了源站。

结果就是： 攻击者构造的请求，成功绕过了 WAF，直接打到了你的源站服务器上！

Kirill Firsov（漏洞发现者）指出： 攻击者可以利用这个漏洞，获取一个确定性的、长效的 Token，对 Cloudflare 背后的源站进行无阻碍的侦查，甚至访问源站上的敏感文件。

04 官方的修复与启示

Cloudflare 在收到报告后（2025年10月），迅速修复了这个 Bug。

修复方案其实很简单： 收紧校验逻辑。只有当请求的 Token 不仅有效，而且明确属于当前请求的主机名（Hostname）时，才禁用 WAF 规则。

如果 Token 是有效的但属于别的域名？对不起，WAF 规则照常开启，该拦截拦截。

05 技术总结

这个案例虽小，但给我们的架构设计敲响了警钟：

• 上下文隔离至关重要

  在做权限校验或白名单时，千万不能只校验“对象是否存在”，必须校验“对象是否归属于当前上下文”。这和常见的越权漏洞（IDOR）原理其实是一样的。

• 纵深防御（Defense in Depth）

  不要把所有的安全希望都寄托在 WAF 这一层。源站本身的安全配置（比如限制只允许 CF IP 访问、Nginx 层的过滤）依然不能丢。

• 对“业务特权”保持警惕

  任何为了业务便利（如自动续签、健康检查）而开的“后门”或“白名单”，都必须经过最严格的安全审计。

这次 Cloudflare 响应很快，表示没有发现该漏洞被恶意利用的证据。但作为技术人，我们不仅要看热闹，更要看门道。

最后问一句： 你们公司的系统里，有没有为了方便第三方回调或者监控，而写的 if (path == "/xxx") return true; 这种代码？赶紧去查查吧！

免责声明：

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

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

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

本文转载自：技术修道场 Hankzheng Hankzheng《深度复盘：如何用一个合法的 Token，穿透 Cloudflare 的铜墙铁壁？》