應用程式安全報告：2023 年第二季

Cloudflare 在網際網路上佔據了獨特的有利位置。從這個位置，我們能夠看到、探索和識別本有可能會被忽視的趨勢。在本報告中，我們正是這樣做的，並分享了我們對網際網路範圍內的應用程式安全趨勢的見解。

本報告是我們的《應用程式安全報告》的第三版。第一版於 2022 年 3 月發佈，第二版於今年早些時候的 3 月份發佈，這是第一份按季度發佈的報告。

自上次報告以來，我們的網路規模更大、速度更快：現在平均每秒可處理 4600 萬個 HTTP 請求，峰值時可達 6300 萬個。我們每秒持續處理大約 2500 萬個 DNS 查詢。每天大約有 2.1 萬億次 DNS 查詢，每月大約有 65 萬億次查詢。這是我們的基礎結構所服務的權威請求和解析程式請求的總和。總結 HTTP 和 DNS 請求，我們可以看到大量惡意流量。僅聚焦 HTTP 請求，2023 年第 2 季度，Cloudflare 平均每天封鎖 1120 億個網路威脅，這就是為本報告提供支援的資料。

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

在這份報告中，我們將提及以下詞彙：

• 已緩解流量：Cloudflare 平台對其套用了「終止」動作的任何重點關注的 HTTP* 請求。其中包括以下動作：BLOCK、CHALLENGE、JS_CHALLENGE 和 MANAGED_CHALLENGE。這不包括套用了以下動作的請求：LOG、SKIP、ALLOW。與去年相比，我們現在排除了 DDoS 緩解系統套用了 CONNECTION_CLOSE 和 FORCE_CONNECTION_CLOSE 動作的請求，因為從技術上講，這些動作只會減慢連線初始化的速度。它們在請求中所占的比例也相對較小。此外，我們改進了有關 CHALLENGE 類型動作的計算，以確保只有未解決的質詢才計入已緩解。如需動作的詳細描述，請參閱我們的開發人員文件。

• 機器人流量/自動化流量：由 Cloudflare 的 Bot Management 系統識別為由機器人產生的 HTTP* 要求，包括機器人分數介於 1 至 29（含）之間的要求。這一點從去年的報告至今並未改變。

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

除非另有說明，否則本文中評估的時間範圍為 2023 年 4 月至 2023 年 6 月（含）的 3 個月期間。

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

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

儘管從 2021 年到 2022 年，每日緩解的 HTTP 請求平均減少了 2 個百分點，達到 6%，但在整個網路中可以清楚地看到惡意活動超過平常的日子。下圖顯示了一個明顯的範例：到 2023 年 5 月底，可以看到峰值達到近 8%。這是由於大型 DDoS 事件和其他活動不遵循標準的每日或每週週期，並且不斷提醒人們，大型惡意事件仍然可以在全球範圍內產生明顯的影響，即使在 Cloudflare 規模上也是如此。

75% 的已緩解 HTTP 請求被徹底封鎖。與之前的報告相比，這一數字下降了 6 個百分點。大多數其他請求都可以透過各種 CHALLENGE 類型動作來緩解，其中受管理的質詢占該類別的約 20%。

在我們之前的報告中，我們的自動化 DDoS 緩解系統平均占到已緩解流量的 50% 以上。在過去的兩個季度中，由於 WAF 採用率的增加，以及組織很可能更好地設定和鎖定其應用程式以免受無用流量的影響，我們看到了一種新趨勢的出現，WAF 緩解的流量超過了 DDoS 緩解。大部分增長是由 WAF 自訂規則 BLOCK 而不是我們的 WAF 受管理規則推動的，這表明這些緩解是由客戶為業務邏輯或相關目的設定的規則產生的。從下圖中可以清楚地看到這一點。

請注意，與 WAF 緩解的總體流量相比，我們的 WAF 受管理規則的緩解流量（黃線）可以忽略不計，這也表明客戶正在採用積極的安全模型，允許已知的良好流量，而不是僅封鎖已知的不良流量。儘管如此，本季度 WAF 受管理規則緩解量也達到了每天 15 億個請求。

當然，我們的 DDoS 緩解容量巨大，並且與我們的 DDoS 第 7 層規則相匹配的流量不應被低估，特別是考慮到我們觀察到網路上出現了許多新型攻擊和僵屍網路。您可以在我們的第二季度 DDoS 威脅報告中深入瞭解 DDoS 攻擊趨勢。

匯總已緩解流量的來源，WAF 目前約占所有緩解流量的 57%。下面的表格中匯總了其他來源，可供參考。

來源

Source	Percentage %
WAF	57%
DDoS Mitigation	34%
IP Reputation	6%
Access Rules	2%
Other	1%

百分比 (%)

WAF

Field	Used in percentage % of rules
Geolocation fields	40%
HTTP URI	31%
IP address	21%
Other HTTP fields (excluding URI)	34%
Bot Management fields	11%
IP reputation score	4%

57%

DDoS 緩解

34%

IP 聲譽

6%

存取規則

Source	Percentage %
HTTP Anomaly	32%
SQLi	13%
Directory Traversal	10%
File Inclusion	9%
DoS	9%
XSS	9%
Software Specific	7%
Broken Authentication	6%
Common Injection	3%
CVE	1%

2%

其他

1%

鑒於客戶定義的 WAF 規則所緩解的流量有所增加，我們認為，更深入地瞭解客戶正在封鎖哪些內容以及他們是如何做到這一點的，將會很有意義。為此，我們檢閱了 WAF 自訂規則中的規則欄位使用情況，以識別常見主題。當然，資料需要正確解讀，因為由於合約和方案層級的不同，並非所有客戶都可以存取所有欄位，但我們仍然可以根據欄位「類別」做出一些推論。透過檢閱整個網路中部署的全部約 700 萬條 WAF 自訂規則並僅關注主要分組，我們得到以下欄位使用情況分佈：

欄位

在規則中的使用百分比

地理位置欄位

40%

HTTP URI

31%

IP 位址

Source	Percentage %
WAF	77%
DDoS Mitigation	13%
IP reputation	5%
Access Rules	3%
Other	1%

21%

其他 HTTP 欄位（不包括 URI）

34%

機器人管理欄位

11%

IP 聲譽評分

4%

值得注意的是，在所有已部署的 WAF 自訂規則中，40% 使用與地理位置相關的欄位來決定如何處理流量。這是一種常用技術，用於實施業務邏輯或排除預計不會產生流量的地區，並有助於減少攻擊面。雖然這些都是粗略的控制，不太可能阻止老練的攻擊者，但它們仍然可以有效地減少攻擊面。

另一個值得注意的觀察結果是，11% 的 WAF 自訂規則中使用了機器人管理相關欄位。隨著越來越多的客戶採用基於機器學習的分類策略來保護其應用程式，這個數字隨著時間的推移而穩步增加。

HTTP 異常仍然是 WAF 受管理規則攔截的最常見攻擊類別，占 WAF 受管理規則總體緩解流量的約 32%。SQLi 上升到第二位，超過了目錄周遊，二者分別占 12.7% 和 9.9%。

如果我們看看 2023 年 4 月初的情況，就會發現 DoS 類別遠遠超過 HTTP 異常類別。DoS 類別中的規則是 WAF 第 7 層 HTTP 簽名，這些簽名足夠具體，可以匹配（並封鎖）單個請求，而無需查看交叉請求行為，並且可以追究到導致阻斷服務 (DoS) 的具體僵屍網路或有效負載。通常（就像這裡的情況一樣），這些請求不是「分散式」攻擊的一部分，因此在類別名稱中沒有代表「分散式」的第一個「D」。

Source	Percentage %
HTTP Anomaly	64%
SQLi	11%
XSS	9%
Software Specific	5%
Command Injection	4%

供參考的表格格式（前 10 大類別）：

來源

百分比 (%)

HTTP 異常

32%

SQLi

13%

目錄周遊

10%

檔案包含

9%

DoS

9%

XSS

9%

軟體特定

7%

驗證受損

6%

常見插入

3%

CVE

1%

縮小範圍並僅基於 DoS 類別進行篩選，我們發現大部分已緩解流量可歸因於一條規則：100031 / ce02fd…（分別為舊 WAF 和新 WAF 規則 ID）。此規則的描述為「Microsoft IIS - DoS，Anomaly:Header:Range - CVE:CVE-2015-1635」，屬於可追溯到 2015 年的 CVE，該 CVE 影響了許多 Microsoft Windows 元件，可導致遠端程式碼執行*。這是一個很好的提醒，舊的 CVE，甚至是 8 年多以前的 CVE，仍然被積極利用來危害可能未修補且仍在執行易受攻擊軟體的電腦。

* 由於規則分類的原因，一些特定於 CVE 的規則仍被指派到更廣泛的類別，如本範例中的 DoS。只有當攻擊有效負載與其他更通用的類別沒有明顯重疊時，才會將規則指派到 CVE 類別中。

另一個有趣的觀察結果是，從 6 月份開始，「失效驗證」規則匹配數有所增加。這一增長還歸因於我們所有客戶（包括我們的免费方案使用者）部署的一條規則：「Wordpress - Broken Access Control, File Inclusion」。此規則會封鎖對 wp-config.php - WordPress 預設設定檔的存取嘗試，該檔案通常位於 Web 伺服器文件根目錄中，但永遠不應該透過 HTTP 直接存取。

同樣，CISA/CSA 最近發佈了一份報告，重點介紹了 2022 年最常被利用的漏洞。我們藉此機會探討了 CISA 報告中提到的每個 CVE 在 Cloudflare 自身資料中的反映情況。CISA/CSA 討論了惡意網路攻擊者在 2022 年經常利用的 12 個漏洞。然而，根據我們的分析，CISA 報告中提到的兩個 CVE 造成了我們在全網看到的絕大多數攻擊流量：Log4J 和 Atlassian Confluence 程式碼插入。我們的資料清楚地表明，前兩名與清單中的其餘成員之間的漏洞利用量存在重大差異。下圖根據我們的記錄比較了 CISA 清單中前 6 個漏洞的攻擊量（以對數刻度）。

Cloudflare 的 Bot Management 繼續獲得重大投資，因為新增了 JavaScript Verified URL 以更好地防禦基於瀏覽器的機器人，Detection ID 現在可在自訂規則中使用，以實現額外的可設定性，以及改進了 UI 以簡化入門。對於自助服務客戶，我們新增了「跳過」Super Bot Fight 模式規則的功能以及對 Wordpress Loopback 請求的支援，以更好地與客戶的應用程式整合並為他們提供所需的保護。

我們對 Bot Management 分類輸出仍然充滿信心。如果我們在分析的時間範圍內繪製機器人分數圖，我們會發現一個非常清晰的分佈，大多數請求要麼被歸類為「肯定是機器人」（得分低於 30 分），要麼被歸類為「肯定是人類」（得分高於 80 分），大多數請求的實際得分低於 2 分或高於 95 分。這相當於在同一時間段內，33% 的流量被歸類為自動化流量（由機器人產生）。在較長一段時間內，我們確實看到整體機器人流量百分比穩定在 29%，這也反映了 Cloudflare Radar 上顯示的資料。

與上次報告相比，未經驗證的機器人 HTTP 流量緩解目前呈下降趨勢（下降 6 個百分點）。然而，WAF 自訂規則中的機器人管理欄位使用率不可忽視，占 11%。這意味著 Cloudflare 上部署了超過 70 萬個 WAF 自訂規則，這些規則依賴機器人訊號來執行某些動作。最常用的欄位是 cf.client.bot，它是 cf.bot_management.verified_bot 的別名，由我們經過驗證的機器人清單提供支援，讓客戶能夠區分「良性」機器人和潛在的「惡意」未經驗證機器人 。

企业方案客戶可以存取更強大的 cf.bot_management.score，它可以直接存取根據每個請求計算的分數，該分數與上一節中用於產生機器人分數分佈圖的分數相同。

查看哪些 Cloudflare 服務正在緩解未經驗證的機器人流量，上述資料也得到了驗證。 儘管我們的 DDoS 緩解系統會自動封鎖所有客戶的 HTTP 流量，但這僅占未經驗證機器人緩解的 13%。與之相對，WAF 以及主要由客戶定義的規則占此類緩解的 77%，遠高於報告開頭討論的所有流量的緩解情況 (57%)。請注意，這裡特別提到的機器人管理指的是我們的「預設」一鍵式規則，這些規則與 WAF 自訂規則中使用的機器人欄位分開計數。

供參考的表格格式：

來源

百分比 (%)

WAF

77%

DDoS 緩解

13%

IP 聲譽

5%

存取規則

3%

其他

1%

Cloudflare 觀察到的 API 流量總體增長速度並未放緩。與上一季度相比，我們現在看到 58% 的總動態流量被歸類為 API 相關流量。 比第一季度增加了 3 個百分點。

我們對 API Gateway 的投資也呈現出類似的增長趨勢。在上一季度，我們發佈了幾項新的 API 安全功能。

首先，我們推出了新的收件匣檢視，使 API Discovery 更易於使用。API Discovery 會清點您的 API 以防止影子 IT 和僵屍 API，現在客戶可以輕鬆篩選以僅顯示 API Discovery 發現的新端點。從 API Discovery 儲存端點會將它們放入我們的端點管理系統中。

接下來，我們新增了僅在 Cloudflare 提供的全新 API 安全功能：透過用戶端行為控制 API 存取的能力。我們稱之為序列緩解。客戶現在可以根據用戶端存取的 API 路徑的順序，建立積極或消極的安全模型。您現在可以確保，只有存取應用程式的使用者才能存取 API，忽略正常應用程式功能而進行暴力嘗試的人將無法存取 API。例如，在銀行應用程式中，您現在可以強制要求，只有在使用者存取了帳戶餘額檢查端點之後，才能存取資金轉帳端點。

我們很高興能在 2023 年的剩餘時間以及以後繼續發佈 API 安全和 API 管理功能。

在過去一個季度中，瀏覽器產生的 API 流量所占比例一直非常穩定。 對於此統計，我們指的是那些不提供基於 HTML 內容的 HTTP 請求，這些內容將由瀏覽器直接呈現，無需進行一些預處理，例如那些通常稱為 AJAX 呼叫的請求，這些請求通常會提供基於 JSON 的回應。

與上一季度一樣，HTTP 異常仍然是 API 流量中被緩解次數最多的攻擊手段。 不過，SQLi 插入攻擊也不容忽視，約占緩解流量總量的 11%，緊隨其後的是 XSS 攻擊，約占 9%。

表格形式供參考（前 5 位）：

來源

百分比 (%)

HTTP 異常

64%

SQLi

11%

XSS

9%

軟體特定

5%

命令資料隱碼

4%

隨著我們將應用程式安全報告改為每季度一次，我們計畫加深一些見解，並提供來自某些較新產品（例如 Page Shield）的額外資料，使我們能夠看到 HTTP 流量之外的內容，並探索第三方線上依賴性的狀態。

請繼續關注 Cloudflare Radar， 以獲取更多應用程式安全報告和見解。