研究人員團隊 北京大學、清華大學、德克薩斯大學達拉斯分校 發布了有關的信息 他們所做的工作是為了能夠識別 他們將一類新的 DoS 攻擊命名為“RangeAmp” 它們基於使用 Range HTTP 標頭來組織通過內容分發網絡 (CDN) 的流量放大。
該方法的本質 事情是， 由於許多 CDN 中處理 Range 標頭的特殊性, 攻擊者 可以請求大文件的一個字節 通過 CDN，但是 CDN 將從目標服務器下載整個文件或更大的數據塊 用於緩存。
根據 CDN 的說法，此類攻擊期間的流量放大程度為 724 至 43330 倍，可用於使傳入的 CDN 流量過載或減少到受害者站點的最終通信通道的帶寬。
Range 標頭允許客戶端確定文件中的位置範圍 應該加載它而不是返回整個文件。
例如，客戶端可以指定“Range: bytes = 0-1023”，服務器將僅傳輸前 1024 個字節的數據。 下載大文件時非常需要此功能：用戶可以暫停下載，然後從中斷的位置繼續下載。 當指定“bytes = 0-0”時，標準規定給出文件中的第一個字節，“bytes = -1” - 最後一個，“bytes = 1-” - 從1個字節到文件末尾。 您可以在一個標頭中傳遞多個範圍，例如“Range: bytes = 0-1023.8192-10240”。
另外， 提出了第二種攻擊方案 （這稱為 RangeAmp 重疊字節範圍 (OBR) 攻擊，旨在增加網絡負載 當流量通過另一個用作代理的 CDN 轉發時（例如，當 Cloudflare 充當前端 (FCDN)、Akamai 充當後端 (BCDN) 時）。 該方法與第一種攻擊類似，但它位於 CDN 內部，允許您在通過其他 CDN 訪問時增加流量，從而增加基礎設施的負載並降低服務質量。
這個想法是攻擊者向 CDN 範圍請求發送多個範圍，例如“bytes=0-,0-,0-...”、“bytes=1-,0-,0-...”或“bytes=-1024,0-,0-...”。
請求中包含大量範圍“0-”， 這意味著文件從零返回到末尾。 由於當第一個 CDN 引用第二個 CDN 時範圍解析不正確，如果最初發送的攻擊請求中存在範圍重複和交集，則會向每個“0-”帶返回完整文件（範圍不會聚合，而是按順序排序）。 此類攻擊的流量放大程度從 53 到 7432 倍不等。
該研究檢查了 13 個 CDN 的行為：Akamai、阿里雲、Azure、CDN77、CDNsun、Cloudflare、CloudFront、Fastly、G-Core Labs、華為雲、KeyCDN、StackPath 和騰訊雲。
研究團隊表示：“不幸的是，儘管我們多次向他們發送電子郵件並嘗試聯繫他們的客戶服務，但 StackPath 沒有提供任何反饋。”
“總的來說，我們已盡力負責任地報告漏洞並提供緩解解決方案。 在本文檔發布之前，相關 CDN 提供商有近七個月的時間來實施緩解技術。”
所有經過審核的 CDN 都允許對目標服務器進行第一類攻擊。 第二個版本的 CDN 攻擊暴露了 6 個服務，其中四個可以充當攻擊中的接口（CDN77、CDNsun、Cloudflare 和 StackPath），三個充當後端（Akamai、Azure 和 StackPath）。
最大的收穫是在 Akamai 和 StackPath 中實現的，它們允許在 Rank 標頭中指示超過 10 個範圍。
CDN 所有者已收到通知 漏洞 大約 7 個月前 截至信息公開時，12家CDN中有13家已經解決了發現的問題或表示願意解決。