共享 CDN 基础设施的 IP 允许名单机制存在固有缺陷：攻击者可在同一 CDN 开设副账号、关闭安全功能、将源站指向目标源 IP，从而绕过原账号的 WAF 与防火墙规则直接访问源站。文章演示了 cdn-proxy 与 cdn-scanner 两个工具，揭示该攻击在 CloudFront、CloudFlare 等主流 CDN 上的可行性，并指出缺乏源站级访问控制是根因。
攻击原理：共享 IP 与七层代理特性
CDN 在 OSI 第七层终结客户端 TCP 连接，再以自身共享 IP 池向源站发起新连接。源站若仅配置 CDN IP 段允许名单，无法区分请求来自合法账号还是攻击者新建的副账号。攻击者只需：① 确认目标源站真实 IP；② 在同一 CDN 注册新账号；③ 关闭 WAF、认证等安全功能；④ 将源站配置指向该 IP。随后流量经副账号进入 CDN 网络，再从共享 IP 池转发至源站，完全规避原账号防护规则。原文指出，CDN 厂商不对源站配置加限制，安全特性仅对预期账号生效，导致此攻击在依赖 IP 允许名单的场景下难以阻断。
工具验证与利用条件
作者开发 cdn-proxy 部署攻击所需基础设施，cdn-scanner 利用该基础设施批量扫描受影响源站，代码托管于 cdn-proxy GitHub 仓库。利用前提包括：目标源站 IP 已泄露或可枚举；目标使用的 CDN 允许任意账号配置任意源站 IP；源站仅依赖 CDN IP 段允许名单，未实施额外认证。原文未给出具体扫描数量、成功率或受影响厂商名单，仅以 CloudFront、CloudFlare 为例说明通用原理。实测中，攻击者账号与受害者账号共享同一 CDN 网络出口 IP，源站侧无法通过四层特征区分流量来源。
缺口与工程对策
根因在于 CDN 将源站访问控制下推至客户，自身不校验源站归属权。工程上可采取：① 在源站层面强制双向 TLS 或预共享密钥，仅信任持有有效凭据的上游；② 在应用层校验 CDN 注入的特有请求头（如 CloudFront 的 `CloudFront-Viewer-Address`、CloudFlare 的 `CF-Connecting-IP` 及签名头），拒绝缺失或伪造头的请求；③ 结合安全组将入站规则细化至 CDN 分配的专用边缘节点 IP（若厂商提供），而非整个公共 IP 段。原文未给出具体部署案例或性能开销数据，上述措施需结合业务可用性评估。
对运维与网络工程师而言，核心启示是：共享 CDN 的 IP 允许名单不等同于身份认证。必须在源站实施应用层凭据校验（mTLS、签名头、专用边缘 IP），并定期扫描源站是否对公网或非预期 CDN 账号暴露。仅依赖厂商提供的 IP 段白名单，无法阻断同网络内的横向绕过。
原文: APNIC Blog（2022-05-19）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog