正文

CDN也会反水为DDOS？揭秘CDN回源策略风险

admin
admin V管理员 /0 评论 /42 阅读
0917
此篇文章发布距今已超过20天，您需要注意文章的内容或图片是否可用！
引言：CDN的“安全悖论”
作为互联网的“加速盾牌”，CDN（内容分发网络）的核心价值在于加速内容交付和抵御DDoS攻击——它通过全球边缘节点缓存静态资源，让用户从最近的节点获取内容，同时替源站挡住海量攻击流量。但当我们深入研究CDN的“回源策略”（即CDN向源站请求资源的规则）时，却发现了一个致命的“安全悖论”：
CDN为了性能优化设计的回源策略，反而成了攻击者用来“反杀”源站的武器。
攻击者可以利用CDN的回源策略，以极小的带宽消耗，触发CDN向源站发起海量请求，最终耗尽源站带宽——这种新型攻击被命名为BtOAmp（Back-to-Origin Amplification）攻击。
更可怕的是，通过测试14家主流CDN（包括Cloudflare、阿里云、Azure、CloudFront等），发现所有厂商都至少存在一种BtOAmp漏洞，部分攻击的放大因子（源站带宽消耗/攻击者带宽消耗）甚至高达10万倍。
今天，我们就来拆解这四种能“穿透CDN防护”的源站攻击，以及背后的安全逻辑。
基础技术： CDN 回源
要知道攻击，首先要知道攻击的对象。
什么是“回源”？
首先，我们需要理解两个关键角色：
  1. CDN边缘节点（Edge Server）：分布在世界各地，离用户最近的服务器，负责缓存内容并快速响应给用户。
  2. 源站（Origin Server）：你的原始服务器，存放着网站最原始、最完整的代码和数据。
回源（Origin Pull） 指的是：当CDN边缘节点上没有用户请求的资源（文件、图片、视频等），或者资源已过期时，边缘节点需要主动向源站请求这个资源。
这个过程就像是：
  • 你家附近的便利店（边缘节点）没有你想要的某种进口啤酒。
  • 便利店老板打电话给城外的总仓库（源站）调货。
  • 总仓库把啤酒送到便利店，便利店一方面卖给你，另一方面也库存一些以备下次之需。
这个“调货”的过程，就是“回源”。
什么是CDN回源策略？
CDN回源策略是一组规则和配置，用于决定CDN边缘节点在何时、何种情况下需要向源站发起请求获取内容。它的核心目标是：在保证用户能访问到最新内容的前提下，最大限度地减少回源次数，从而降低源站压力、提升访问速度和节省带宽成本。
回源行为主要由以下几种策略和条件触发：
  1. 缓存未命中（Cache Miss）
这是最常见的原因。当用户请求一个资源时，CDN边缘节点发现自己根本没有缓存这个资源，它会立即回源去拉取。
  • 场景：你的网站新发布了一篇文章，附了一张新图片 new-image.jpg。第一个用户访问时，全球所有CDN节点上都没有这张图，所以第一个请求该图片的用户会触发回源，之后的用户就能从就近的CDN节点缓存中快速读取。
  1. 缓存过期（Cache Expired）
CDN缓存不是永久保存的，每个文件都有一个“存活时间”（TTL）。当边缘节点上的缓存文件超过了设置的TTL时间，它就被认为是过期的。当下一个用户请求这个已过期的资源时，CDN节点会回源站验证文件是否已被修改。
  • 场景：你为 style.css 文件设置了7天的缓存时间。8天后有用户访问这个CSS文件，CDN节点会回源站检查这个CSS文件是否有更新。如果有更新，则拉取新版本；如果没更新，源站会返回304（Not Modified），CDN节点会刷新该缓存的TTL时间并继续提供服务。
  1. 强制刷新（Purge/Refresh）
这是一种主动行为。开发者或管理员手动强制清除CDN节点上的缓存。随后的用户请求就会触发回源，拉取源站的最新资源。
  • 场景：你的网站上线后发现了CSS文件有一个严重的bug，修复后立即在CDN控制台提交了“刷新缓存”操作。这样所有用户再访问时，CDN就会回源拉取修复后的新CSS文件。
  1. 动态内容（Dynamic Content）
根据规则，CDN会识别并不缓存动态请求（例如：/api/userinfo, /login.php）。对于这类请求，每一个用户的请求都会被CDN节点直接透传回源站，由源站处理并返回结果。
  • 场景：用户登录请求，包含了个人账户信息，每个请求都不同，因此CDN不会缓存，每次都回源。
  1. 自定义规则（Custom Rules）
高级CDN服务允许你设置非常精细的回源策略：
  • 根据文件类型：例如，总是回源请求 .php 文件，而缓存 .jpg 文件。
  • 根据请求路径（目录）：例如，/static/ 目录下的资源缓存1年，/api/ 目录下的资源不缓存。
  • 根据查询字符串（Query String）：可以忽略或包含URL中的 ?key=value 参数来作为缓存键的一部分。
风险思考：CDN的“回源策略”为何成为攻击入口？
要理解一开始提到的BtOAmp攻击，首先得明确CDN的回源策略——当CDN边缘节点没有缓存用户请求的资源时，会向源站（即网站的原始服务器）发送请求，获取资源后缓存并返回给用户。
为了优化性能，CDN厂商设计了多种回源策略，比如：
  • 图像优化：根据客户端设备自动裁剪、压缩图像（比如把4K图转换成1080P）；
  • 请求修改：允许用户自定义回源的HTTP头或URL（比如添加身份验证头）；
  • 方法转换：将HEAD请求转为GET请求（预拉取资源以提高缓存命中率）；
  • 连接解耦：客户端断开连接后，CDN仍保持与源站的连接（继续缓存资源）。
这些策略的核心是“用源站的资源换用户体验”——但问题在于，没有行业标准约束回源策略的安全性，厂商为了竞争往往优先性能，忽略了对“资源请求量”的限制。
当攻击者利用这些策略，让CDN从源站拉取的资源量远远超过用户实际需要的量时，源站的带宽就会被“无意义的请求”耗尽——这就是BtOAmp攻击的本质。
拆解四种BtOAmp攻击：从原理到实战数据
BtOAmp攻击分为四类，每类都精准命中CDN回源策略的“性能优先”漏洞。我们逐一分析：
一、图像优化攻击：用1像素图“榨干”源站带宽
攻击面：CDN的图像裁剪与压缩功能
CDN的图像优化功能原本是为了让手机用户快速加载图片——比如将10MB的4K图裁剪成1MB的1080P图，或转换成更小的WebP格式。但攻击者发现：只要让CDN从源站拉取大尺寸原图，再裁剪成1像素的极小图，就能让源站输出大量无用数据。
攻击原理
  1. 攻击者向CDN发送请求：“请把源站的4K大图（比如10MB）裁剪成1x1像素的图”；
  2. CDN从源站拉取完整的4K大图（消耗源站10MB带宽）；
  3. CDN将大图裁剪成1像素（仅几字节），返回给攻击者；
  4. 源站的带宽被“拉取大图”耗尽，而攻击者仅消耗几字节带宽。
实战数据：放大因子高达1011倍
测试了不同图像格式的放大因子（见下表）：
  • Cloudflare处理BMP/TIFF格式时，即使返回“415不支持媒体类型”，仍会拉取原图，放大因子高达1011倍；
  • 阿里云对PNG图的放大因子为111倍，对BMP图为126倍；
  • 组合“裁剪+压缩”能进一步提高放大因子——比如将1x1像素的图再转换成WebP格式，放大因子可叠加。
二、请求修改攻击：用“肥大”的HTTP头/URL压垮源站
攻击面：CDN的“自定义回源请求”功能
为了满足用户的个性化需求，CDN允许用户修改回源的HTTP头（比如添加自定义认证信息）或URL（比如重写资源路径）。但厂商对“HTTP头大小”“URL长度”的限制极为宽松——比如Bunny允许添加1MB大小的HTTP头，Edgio允许URL长度超过10KB。
攻击原理
  1. 攻击者注册CDN服务，配置“回源时添加100个200KB的HTTP头”，或“将URL从/a重写为/a重复1000次”；
  2. 攻击者向CDN发送简单的POST请求（比如/a）；
  3. CDN将请求“放大”成包含100个大HTTP头、超长URL的请求，发送给源站；
  4. 源站需要处理这些“肥大”的请求，带宽被快速耗尽。
实战数据：放大因子高达93077倍
测试了12家CDN的请求修改攻击放大因子（见下表）：
  • Bunny的放大因子最高，达93077倍（因为允许1MB的HTTP头）；
  • Edgio的放大因子为5352倍（允许10KB的URL）；
  • 攻击者还可以级联多个CDN（比如CloudFront→Bunny→源站），每个CDN都放大请求，最终放大因子呈指数级增长。
三、方法转换攻击：用HEAD请求“骗”走源站的完整资源
攻击面：CDN的“HEAD→GET”转换策略
HTTP HEAD请求的设计初衷是“仅获取资源的元数据（比如文件大小），不下载内容”——这本来是为了节省带宽。但很多CDN为了提高缓存命中率，会自动将HEAD请求转为GET请求（预拉取完整资源缓存），即使源站支持HEAD请求。
攻击原理
  1. 攻击者向CDN发送HEAD请求：“请告诉我源站10MB文件的大小”；
  2. CDN将HEAD请求转为GET请求，从源站拉取完整的10MB文件（消耗源站10MB带宽）；
  3. CDN仅向攻击者返回文件的元数据（几字节的HTTP头）；
  4. 源站的带宽被“拉取完整文件”耗尽，而攻击者仅获取元数据。
实战数据：放大因子与文件大小成正比
测试了7家易受攻击的CDN（见下表）：
  • G-core对25MB文件的放大因子高达53352倍；
  • 阿里云对10MB文件的放大因子为13059倍；
  • Fastly虽然转换HEAD→GET，但会在收到响应头后立即关闭连接，因此放大因子固定为469倍（不受文件大小影响）。
四、连接解耦攻击：用“断开连接”让CDN持续拉取资源
攻击面：CDN的“连接保持”策略
CDN的连接解耦策略原本是为了“容错”——当用户突然断开连接（比如关闭浏览器），CDN仍保持与源站的连接，继续下载资源并缓存，以便后续用户请求。但攻击者发现：只要用Transfer-Encoding: chunked（分块传输），就能强制CDN保持连接，即使用户断开。
攻击原理
  1. 攻击者向CDN发送GET请求：“请下载源站的25MB文件”，并指定Transfer-Encoding: chunked；
  2. CDN从源站开始下载25MB文件；
  3. 攻击者立即断开与CDN的连接；
  4. CDN因chunked传输，继续保持与源站的连接，直到下载完整个25MB文件；
  5. 源站的带宽被“无用户接收的下载”耗尽。
实战数据：放大因子高达104862倍
测试了14家CDN的连接解耦策略（见下表）：
  • Azure对25MB文件的放大因子高达104862倍；
  • 阿里云、百度的放大因子也超过10万倍；
  • CloudFront、Edgio等厂商会同步关闭连接，因此不受此攻击影响。
真实世界的威胁：小带宽引发大灾难
研究者用真实环境验证了BtOAmp攻击的破坏力：
  • 攻击者使用新加坡的30Mbps VPS，向美国硅谷的100Mbps源站发起攻击；
  • 图像优化攻击：攻击者用<10Kbps带宽，就能让源站带宽跑满100Mbps；
  • 方法转换攻击：攻击者用7Kbps带宽，就能耗尽源站带宽；
  • 连接解耦攻击：攻击者用<10Kbps带宽，就能让源站带宽达到峰值。
更可怕的是，攻击请求是“合法”的——CDN认为这些请求是用户的正常需求，因此不会被DDoS防护系统拦截。正如俗话中所说：“这是‘小火花引发大火灾’的完美诠释”。
如何防御BtOAmp攻击？四大关键措施
针对四类攻击提出了针对性防御方案，部分厂商已经落地：
  1. 限制回源参数的“任性度”
  • 对图像优化：默认限制裁剪尺寸为常见分辨率（如1080P），用户自定义需审核；
  • 对请求修改：限制HTTP头的大小（比如单头不超过1KB）、数量（比如不超过20个），URL长度不超过2KB；
  • 阿里云、G-core已通过“缓存原图”修复了图像优化攻击——CDN第一次拉取原图后缓存，后续请求不再回源。
  • 遵循RFC标准转发请求
    • 禁止默认将HEAD请求转为GET请求，仅允许用户手动配置；
    • 确保CDN转发的请求与用户请求“一致”（比如用户发HEAD，CDN就发HEAD）。
  • 同步客户端与源站的连接状态
    • 当用户断开与CDN的连接后，CDN应在3秒内关闭与源站的连接；
    • 禁止用Transfer-Encoding: chunked强制保持连接。
  • 严格验证源站所有权
    • CDN厂商需验证用户是否真的拥有源站（比如通过DNS验证、文件验证），防止攻击者将他人源站配置为自己的CDN回源地址；
    • 目前仅阿里云要求用户通过银行卡验证身份，其他厂商的验证机制仍较宽松。
    结语：CDN的安全需要“性能与安全的平衡”
    CDN的本质是“用资源换体验”，但当“资源消耗”不受控制时，就会变成“用源站的安全换体验”。BtOAmp攻击的出现，提醒我们：
    • 没有“绝对安全”的基础设施，性能优化的每一步都要考虑安全；
    • 行业需要统一的回源策略安全标准，避免厂商“为了竞争牺牲安全”；
    • 源站管理员需关注CDN的回源配置，避免“过度授权”。
    CDN是互联网的 backbone，但 backbone 的漏洞会让整个网络颤抖。


    推荐站内搜索：最好用的开发软件、免费开源系统、渗透测试工具云盘下载、最新渗透测试资料、最新黑客工具下载……
    宙飒天下