应用程序安全报告：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 机器人管理系统识别为由机器人产生的任何 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 月份开始，“失效身份验证”规则匹配数有所增加。这一增长还归因于我们所有客户（包括我们的 Free 方案用户）部署的一条规则：“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 的机器人管理继续获得重大投资，因为添加了 JavaScript Verified URL 以更好地防御基于浏览器的机器人，Detection ID 现在可在自定义规则中使用，以实现额外的可配置性，以及改进了 UI 以简化入门。对于自助服务客户，我们添加了“跳过” Super Bot Fight 模式规则的功能以及对 Wordpress Loopback 请求的支持，以更好地与客户的应用程序集成并为他们提供所需的保护。

我们对机器人管理分类输出仍然充满信心。如果我们在分析的时间范围内绘制机器人分数图，我们会发现一个非常清晰的分布，大多数请求要么被归类为“肯定是机器人”（得分低于 30 分），要么被归类为“肯定是人类”（得分高于 80 分），大多数请求的实际得分低于 2 分或高于 95 分。这相当于在同一时间段内，33% 的流量被归类为自动化流量（由机器人生成）。在较长一段时间内，我们确实看到整体机器人流量百分比稳定在 29%，这也反映了 Cloudflare Radar 上显示的数据。

与上次报告相比，未经验证的机器人 HTTP 流量缓解目前呈下降趋势（下降 6 个百分点）。然而，WAF 自定义规则中的机器人管理字段使用率不可忽视，占 11%。这意味着 Cloudflare 上部署了超过 70 万个 WAF 自定义规则，这些规则依赖机器人信号来执行某些操作。最常用的字段是 cf.client.bot，它是 cf.bot_management.verified_bot 的别名，由我们经过验证的机器人列表提供支持，让客户能够区分“良性”机器人和潜在的“恶意”未经验证机器人 。

Enterprise 方案客户可以访问更强大的 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， 以获取更多应用程序安全报告和见解。