訂閱以接收新文章的通知:

應用程式安全報告:2024 年更新

2024-07-11

閱讀時間:10 分鐘
本貼文還提供以下語言版本:EnglishFrançaisDeutsch日本語한국어Español简体中文

在過去十二個月中,網際網路安全狀況發生了巨大變化。地緣政治的不確定性,加上全球許多國家 2024 年投票季的活躍,導致網際網路上的惡意流量活動大幅增加。在本報告中,我們探討了 Cloudflare 對網際網路應用程式安全的看法。

Application Security report: 2024 update

本報告是我們的應用程式安全報告的第四版,也是我們 2023 年第二季報告的正式更新。本報告中的新增部分重點在於 Web 應用程式環境中的用戶端安全性。

在整個報告中,我們討論了各種見解。從全球角度來看,整個網路的流量緩解率現在平均為 7%,其中一半以上來自 WAF 和機器人緩解。雖然 DDoS 攻擊仍然是針對 Web 應用程式的第一大攻擊手段,但有針對性的 CVE 攻擊也值得關注,因為我們發現,在概念驗證發佈後僅 22 分鐘就出現了漏洞利用。

專注於機器人,我們觀察到的所有流量中大約有三分之一是自動化流量,其中絕大多數 (93%) 不是由 Cloudflare 已驗證清單中的機器人產生的,且可能是惡意流量。

API 流量也在不斷成長,目前佔所有流量的 60%,也許更令人擔憂的是,組織有多達四分之一的 API 端點未被計算在內。

我們還涉及用戶端安全性以及 Web 應用程式中第三方整合的激增。根據 Page Shield 資料,企業網站平均整合 47 個第三方端點。

另外值得一提的是,自上次報告以來,我們從中收集資料和見解的網路變得更大更快:我們現在平均每秒處理 5,700 萬個 HTTP 請求(年增 23.9%),峰值時達到 7,700 萬個 HTTP 請求(年增 22.2%)。從 DNS 角度來看,我們每秒處理 3,500 萬次 DNS 查詢(年增 40%)。這是我們的基礎架構所服務的權威請求和解析程式請求的總和。

也許更值得注意的是,僅關注 HTTP 請求,在 2024 年第一季,Cloudflare 平均每天封鎖 2,090 億個網路威脅(年增 86.6%)。與去年同期相比,這是相當顯著的增長。

像往常一樣,在深入討論之前,我們需要先定義一下我們的詞彙。

定義

在這份報告中,我們將提及以下詞彙:

  • **已緩解流量:**Cloudflare 平台對其套用了「終止」動作的任何重點關注的 HTTP* 請求。其中包括以下動作:BLOCKCHALLENGEJS_CHALLENGEMANAGED_CHALLENGE。這不包括套用了以下動作的請求:LOGSKIPALLOW。它們在請求中所占的比例也相對較小。此外,我們改進了有關 CHALLENGE 類型動作的計算,以確保只有未解決的質詢才計入已緩解。如需動作的詳細描述,請參閱我們的開發人員文件。這與去年的報告相比沒有變化。

  • 傀儡程式流量/自動化流量:任何由 Cloudflare 的傀儡程式管理系統識別為由傀儡程式產生的 HTTP* 要求,包括傀儡程式分數介於 1 至 29(含)之間的要求。這一點從去年的報告至今並未改變。

  • API 流量:任何含有 XML 或 JSON 等回應內容類型的 HTTP* 要求。其中回應內容類型(由使用者代理指定)無法用於緩解的要求,因此會改為使用同等的 Accept。在後者的案例中,不會完全將 API 流量列入考量,但是在取得深入解析方面還是具有相當不錯的代表性。這與去年的報告相比沒有變化。

除非另有說明,本文評估的時間範圍為 2023 年 4 月 1 日至 2024 年 3 月 31 日(含)。

最後要注意的是,此資料僅依據在 Cloudflare 網路中觀察到的流量來計算,不一定代表網際網路中的整體 HTTP 流量模式。

*提及 HTTP 流量時,同時表示 HTTP 和 HTTPS。

全球流量深入解析

平均每天緩解的流量增長到近 7%

與先前的 12 個月期間相比,Cloudflare 在 2023 年第二季至 2024 年第一季期間緩解了更高比例的應用程式層流量和第 7 層 (L7) DDoS 攻擊,從 6% 成長到 6.8 %。

**圖 1:**過去 12 個月已緩解 HTTP 流量增長百分比

在大型全球攻擊活動期間,我們可以觀察到緩解流量的峰值接近所有 HTTP 流量的 12%。這些峰值比我們在整個網路中觀察到的峰值要大得多。

WAF 和機器人緩解流量佔所有已緩解流量的 53.9%

隨著 Cloudflare 平台繼續公開更多訊號來識別潛在的惡意流量,客戶一直在 WAF 自訂規則中積極使用這些訊號來改善其安全狀態。範例訊號包括我們的 WAF Attack Score(用於識別惡意負載)和我們的 Bot Score(用於識別自動化流量)。

在 WAF 和機器人緩解之後,HTTP DDoS 規則是已緩解流量的第二大來源。IP 聲譽(使用我們的 IP 威脅評分來封鎖流量)和存取規則(僅封鎖 IP 和國家/地區)緊隨其後,位居第三和第四位。

圖 2:依 Cloudflare 產品群組劃分的已緩解流量

概念驗證發布後最快 22 分鐘內就出現了 CVE 漏洞利用

zero-day 漏洞(也稱為 zero-day 威脅)正在增加,所披露 CVE 的武器化速度也在加快。2023 年,共有 97 個 zero-day 漏洞被利用,2022 年至 2023 年間披露的 CVE 數量增加了 15%。

縱觀針對客戶的 CVE 漏洞利用嘗試,Cloudflare 主要觀察到掃描活動,其次是命令插入,以及一些在線上提供 PoC 的漏洞利用嘗試,包括 Apache CVE-2023-50164CVE-2022-33891、Coldfusion CVE-2023-29298 CVE-2023-38203CVE-2023-26360,以及 MobileIron CVE-2023-35082

CVE 漏洞利用嘗試活動的這種趨勢表明,攻擊者首先會瞄準最簡單的目標,以及針對舊漏洞持續進行活動在某些情況下可能會取得成功。

例如,Cloudflare 在 3 月 4 日 19:45 UTC 時間(即概念驗證程式碼發佈後僅 22 分鐘)觀察到 CVE-2024-27198(JetBrains TeamCity 驗證繞過)的利用嘗試。

**圖 3:**JetBrains TeamCity 驗證繞過時間表

所披露 CVE 的利用速度通常比人類建立 WAF 規則或建立和部署修補程式以緩解攻擊的速度更快。這也適用於我們自己維護 WAF 受管理規則集的內部安全分析師團隊,這使我們能夠將人工書寫簽名與基於 ML 的方法相結合,以實現低誤判和回應速度之間的最佳平衡。

CVE speed of exploitation by attackers

當我們著重關注部分 CVE 類別時,可以清楚地看到來自特定威脅執行者的 CVE 漏洞利用活動。例如,如果我們篩選導致遠端程式碼執行 (RCE) 的 CVE,則在 2023 年底和 2024 年初,我們可以清楚地看到利用 Apache 和 Adobe 安裝的嘗試,以及今年 5 月針對 Citrix 的一次值得註意的活動。

**圖 4:**程式碼執行 CVE 的全球每日請求數

當關注其他 CVE 或特定攻擊類別時,類似的檢視畫面會變得清晰可見。

CVE exploit campaigns clearly visible in attack traffic

DDoS 攻擊仍然是針對 Web 應用程式最常見的攻擊

DDoS 攻擊仍然是針對 Web 應用程式最常見的攻擊類型,在所考慮的時間段內,DDoS 攻擊佔所有被緩解的應用程式流量的 37.1%。

**圖 5:**一段時間內的 HTTP DDoS 攻擊量

我們看到巨流量攻擊在 2024 年 2 月和 3 月出現了大幅增長。除了攻擊活動增加之外,這在一定程度上是由於我們的團隊部署了改進的偵測。僅在 2024 年第一季,Cloudflare 的自動化防禦就緩解了 450 萬次 DDoS 攻擊,相當於 Cloudflare 在 2023 年緩解的所有 DDoS 攻擊的 32%。具體而言,應用程式層 HTTP DDoS 攻擊較去年同期成長 93%,較上一季 (QoQ) 成長 51%。

Cloudflare 關聯 DDoS 攻擊流量,並透過查看事件開始和結束時間以及目標目的地來定義獨特的攻擊。

發起 DDoS 攻擊的動機包括針對特定組織以獲取經濟利益(勒索)、測試殭屍網路的能力,以及出於政治原因而針對機構和國家/地區。例如,Cloudflare 觀察到瑞典於 2024 年 3 月 7 日加入北約聯盟後,其遭受的 DDoS 攻擊增加了 466%。這與芬蘭 2023 年加入北約期間觀察到的 DDoS 模式類似。DDoS 攻擊本身的規模也在不斷擴大。

2023 年 8 月,Cloudflare 緩解了一次超容量 HTTP/2 Rapid Reset DDoS 攻擊,該攻擊峰值達到每秒 2.01 億個請求 (rps),是先前觀察到的任何攻擊的三倍。在這次攻擊中,威脅執行者利用了 HTTP/2 通訊協定中的 zero-day 漏洞,該漏洞有可能導致幾乎任何支援 HTTP/2 的伺服器或應用程式癱瘓。這凸顯了 DDoS 漏洞對於未受保護的組織來說是多麼具有威脅性。

遊戲和博彩成為 DDoS 攻擊的最大目標產業,其次是網際網路科技公司和加密貨幣挖礦。

**圖 6:**Cloudflare 發現的最大 HTTP DDoS 攻擊(依年份)

傀儡程式流量深入解析

Largest DDoS attacks by year

Cloudflare 繼續大力投資我們的機器人偵測系統。7 月初,我們宣佈推出 AIndependence,來幫助內容創作者維護安全的網際網路,提供全新的「快速鍵」來封鎖所有 AI 機器人。所有客戶均可使用此功能,包括我們的免費方案客戶。

其他補充系統也取得了重大進展,例如我們的 Turnstile 產品,這是一種使用者友好、保護隱私的 CAPTCHA 替代方案。

所有這些系統和技術幫助我們更好地識別和區分人類流量與自動化機器人流量。

平均而言,機器人佔所有應用程式流量的三分之一

Cloudflare 處理的所有應用程式流量中,有 31.2% 是機器人流量。過去三年來,這一比例一直保持相對穩定(徘徊在 30% 左右)。

機器人流量一詞可能帶有負面意義,但實際上機器人流量並非一定是好的或是不好的;這一切都取決於機器人的目的。有些是「善意」的並且執行所需的服務,例如客戶服務聊天機器人和授權的搜尋引擎爬蟲。但有些機器人濫用線上產品或服務,需要予以封鎖。

不同的應用程式擁有者對於他們認為的「惡意」機器人可能有不同的標準。例如,一些組織可能希望阻止競爭對手為打價格戰而部署的內容剽竊機器人,而不銷售產品或服務的組織可能不會那麼關心內容剽竊。眾所周知,善意機器人被 Cloudflare 歸類為「經過驗證的機器人」。

在我們發現的機器人中,有 93% 是未經驗證的機器人,而且可能是惡意的

未經驗證的機器人通常是出於破壞性和有害目的而建立的,例如囤積庫存、發動 DDoS 攻擊或試圖透過暴力或憑證填充來接管帳戶。經過驗證的機器人是已知安全的機器人,例如搜尋引擎爬蟲,Cloudflare 旨在驗證所有主要合法機器人營運商。如需所有經過驗證的機器人清單,請參見我們的文件。

利用機器人的攻擊者最關注能為他們帶來高額經濟效益的產業。例如,消費品網站通常是庫存囤積機器人以及競爭對手或旨在利用某種套利的自動化應用程式(例如 sneaker bot)執行的價格抓取機器人的目標。這種類型的濫用可能會對目標組織產生重大的財務影響。

**圖 8:**機器人流量每日佔比中位數最高的產業

API 流量深入解析

消費者和終端使用者期望由 API 提供支援的動態 Web 和行動體驗。對企業而言,API 增強了競爭優勢——更強大的商業智慧、更快速的雲端部署、全新 AI 功能的整合,等等。

然而,API 為外部各方提供了額外的攻擊面來存取應用程式和資料庫(這些同樣需要受到保護),從而帶來新的風險。因此,我們現在觀察到的許多攻擊都是先針對 API 端點,而不是針對傳統的 Web 介面。

額外的安全性問題當然不會減緩 API 優先應用程式的採用。

60% 的動態(不可快取)流量與 API 相關

與去年的報告相比,這一數字增加了兩個百分點。在這 60% 中,平均約 4% 是透過我們的安全系統緩解的。

**圖 9:**緩解的 API 流量佔比

1 月 11 日至 17 日期間出現大幅增長,僅該時期的流量份額就增加了近 10%。這是由於特定客戶區域接收了由 WAF 自訂規則緩解的攻擊流量。

% of API mitigated traffic

深入研究 API 流量的緩解來源,我們發現 WAF 是最大的貢獻者,因為標準惡意負載通常同時適用於 API 端點和標準 Web 應用程式。

**圖 10:**依產品群組劃分的 API 緩解流量

四分之一的 API 是「影子 API」

WAF contributes towards 67% of all API mitigated traffic

您無法保護您看不到的東西。而且,許多組織缺乏準確的 API 清單,即使他們相信自己可以正確識別 API 流量。

使用我們專有的機器學習模型,不僅掃描已知的 API 呼叫,還掃描所有 HTTP 請求(識別可能下落不明的 API 流量),我們發現組織擁有的面向公眾的 API 端點比他們知道的多 33%。這個數字是中位數,它是透過比較基於機器學習的探索與客戶提供的工作階段識別碼偵測到的 API 端點數量來計算的。

這表明近四分之一的 API 是「影子 API」,即沒有得到適當的清查和保護。

用戶端風險

大多數組織的 Web 應用程式依賴第三方提供者的單獨程式或程式碼段(通常以 JavaScript 編碼)。使用第三方指令碼可以加速現代 Web 應用程式的開發,並允許組織更快地將功能推向市場,而無需在內部建立所有新的應用程式功能。

使用 Cloudflare 的用戶端安全產品 Page Shield,我們可以瞭解網際網路上使用的第三方程式庫的受歡迎程度以及它們給組織帶來的風險。最近,由於 Polyfill.io 事件影響了超過十萬個網站,這一點變得非常重要。

企業應用程式平均使用 47 個第三方指令碼

Cloudflare 的典型企業客戶平均使用 47 個第三方指令碼,中位數為 20 個第三方指令碼。由於 SaaS 提供者通常擁有數千個可能全部使用第三方指令碼的子網域,因此平均值遠高於中位數。以下是 Cloudflare 客戶常用的一些主要第三方指令碼提供者:

  • Google (Tag Manager、Analytics、Ads、Translate、reCAPTCHA、YouTube)

  • Meta(Facebook Pixel、Instagram)

  • Cloudflare (Web Analytics)

  • jsDelivr

  • New Relic

  • Appcues

  • Microsoft(Clarity、Bing、LinkedIn)

  • jQuery

  • WordPress(Web Analytics、託管外掛程式)

  • Pinterest

  • UNPKG

  • TikTok

  • Hotjar

雖然很有用,但第三方軟體相依性通常由終端使用者的瀏覽器直接載入(即它們在用戶端載入)——由於組織無法直接控制第三方安全措施,這種做法會將組織及其客戶置於風險之中。例如,根據 Verizon 的 2024 年資料外洩調查報告,在零售業,18% 的資料外洩源自 Magecart 式攻擊

企業應用程式平均連線到近 50 個第三方

將第三方指令碼載入到您的網站中會帶來風險,當該指令碼「呼叫來源」提交資料以執行預期功能時則更是如此。一個典型的範例是 Google Analytics:每當使用者執行動作時,Google Analytics 指令碼就會將資料提交回 Google 伺服器。我們將這些視為連線。

平均而言,每個企業網站連線到 50 個單獨的第三方目的地,中位數為 15 個。這些連線中的每一個都會帶來潛在的用戶端安全風險,因為攻擊者經常使用它們來外洩未被注意到的其他資料。

以下是 Cloudflare 客戶常用的一些主要第三方連線:

  • Google(Analytics、Ads)

  • Microsoft(Clarity、Bing、LinkedIn)

  • Meta (Facebook Pixel)

  • Hotjar

  • Kaspersky

  • Sentry

  • Criteo

  • tawk.to

  • OneTrust

  • New Relic

  • PayPal

未來展望

此應用程式安全報告還提供 PDF 格式,其中包含有關如何解決所提出的許多問題的其他建議以及其他見解。

我們也在 Cloudflare Radar 上發佈了許多帶有動態圖表的報告,使其成為瞭解網際網路最新狀態的絕佳資源。

我們保護整個企業網路,協助客戶有效地建置網際網路規模的應用程式,加速任何網站或網際網路應用程式抵禦 DDoS 攻擊,阻止駭客入侵,並且可以協助您實現 Zero Trust

從任何裝置造訪 1.1.1.1,即可開始使用我們的免費應用程式,讓您的網際網路更快速、更安全。

若要進一步瞭解我們協助打造更好的網際網路的使命,請從這裡開始。如果您正在尋找新的職業方向,請查看我們的職缺
Application SecurityWAFBot ManagementAPI

在 X 上進行關注

Michael Tremante|@MichaelTremante
Cloudflare|@cloudflare

相關貼文

2024年9月27日 下午1:00

AI Everywhere with the WAF Rule Builder Assistant, Cloudflare Radar AI Insights, and updated AI bot protection

This year for Cloudflare’s birthday, we’ve extended our AI Assistant capabilities to help you build new WAF rules, added new AI bot & crawler traffic insights to Radar, and given customers new AI bot blocking capabilities...

2024年9月24日 下午1:00

Automatically generating Cloudflare’s Terraform provider

The Cloudflare Terraform provider used to be manually maintained. With the help of our existing OpenAPI code generation pipeline, we’re now automatically generating the provider for better endpoint and attribute coverage, faster updates when new products are announced and a new API documentation site to top it all off. Read on to see how we pulled it all together....