资讯分享|运用序列分析自动侦测 API 滥用

今天，我们推出了适用于 API 的 Cloudflare 序列分析。透过序列分析，订阅 API Gateway 的客户就能够检视对其端点最重要的 API 呼叫序列。这项新功能可协助客户将保护功能优先套用至最重要的端点。

什么是序列？简单地说，序列就是特定访客在浏览网站、使用行动应用程式或透过 API 与 B2B 合作伙伴互动时所发出之 HTTP API 请求的时间顺序清单。例如，在银行资金转帐期间所执行之序列的一部分可能如下所示：

为什么关注 API 安全性的序列很重要？如果上述 API 在收到 POST /api/v1/transferFunds 请求之前未收到前面的任何请求，则会很可疑。想一想：API 用户端如何在不列出使用者的相关帐户 ID 情况下得知相关资讯？API 用户端如何得知有多少资金可供转帐？虽然此範例可能很明显，但对任何特定生产性 API 的海量 API 请求可能使分析人员难以发现可疑的使用情况。
在安全方面，防御无法由人类团队筛选之海量威胁的其中一种方法是建立正面安全性模型。依预设，您将允许所有已知的安全或良性流量并阻止其他所有流量，而不是尝试阻止所有可能构成威胁的内容。
客户可能已经在两个主要领域使用 API 闸道建立正面安全性模型： 大规模滥用防护和结构描述验证。序列将构成 API 流量正面安全性模型的第三个支柱。API 闸道将能够在任何指定 API 序列中强制实施端点的优先顺序。透过在 API 序列中建立优先顺序，API 闸道将记录或阻止任何不符合预期的流量，从而减少滥用流量。

依序列侦测滥用
当攻击者试图以滥用方式使资料外流时，很少会遵循预期的 API 流量模式。攻击通常使用特殊软体来「模糊」API，传送具有不同请求参数的多个请求，以期从 API 中找到指示资料外流机会的意外回应。攻击者还可以手动传送请求至 API，试图诱骗 API 执行未经授权的动作，例如透过损坏的物件层级验证 (Broken Object Level Authentication) 攻击授予攻击者更高的权限或资料存取权。利用速率限制保护 API 是一种常见的最佳做法；但是，在上述两个範例中，攻击者可能会故意缓慢执行请求序列，以试图阻止大规模滥用侦测。
再次考虑上面的请求序列，但这次假设攻击者複製合法的资金转帐请求并修改请求有效负载以试图欺骗系统：

如果客户事先知道资金转帐端点对于保护至关重要，并且在一个序列中只会发生一次，他们就可以编写规则来确保永远不会连续呼叫两次，并且 GET /balance 一律优先于 POST /transferFunds。但是，如果事先不知道哪些端点序列对于保护至关重要， 客户如何才能知道要定义哪些规则？低速率限制风险太大，因为 API 使用者可能会合法地在短时间内执行多个资金转帐请求。在现实中，能够防止此类滥用的工具很少，大多数客户在滥用发生后只能被动地与应用程式团队和防欺诈部门一起清理滥用行为。
最终，我们认为，要让客户能够定义关于 API 请求序列的正面安全性模型，需要採取三管齐下的方法：

序列分析：判定 API 请求的哪些序列发生以及何时发生，并将资料汇总为易于理解的表单。序列滥用侦测：判定哪些 API 请求序列可能是良性或恶意来源。序列缓解：判定有关 API 请求序列的相关规则，以决定允许或阻止哪些流量。

建立序列时可能遇到的挑战
序列分析带来了一些比较难以解决的技术挑战，因为工作阶段可能存留很长时间，并且可能包含很多请求。因此，仅透过工作阶段识别码来定义序列还不够。因此，我们有必要开发一种能够自动识别特定工作阶段中发生的多个序列的解决方案。此外，由于重要序列不一定仅以容量为特性，并且可能的序列集会很大，因此有必要开发一种能够识别重要序列的解决方案，而不是简单地呈现频繁执行的序列。
为了帮助使用 api.cloudflare.com 範例说明这些挑战，我们可以按工作阶段对 API 请求进行分组，并标绘出不同序列的数量与序列长度的关係：

我们将基于一个小时的快照进行标绘，其中包含大约 88,000 个工作阶段和 2.6 亿个 API 请求，具有 301 个不同的 API 端点。我们对每个工作阶段套用固定长度的滑动视窗，然后计算由于套用滑动视窗而观察到之不同固定长度序列的总数（「n-grams」），以此来处理资料。绘图中将显示视窗大小（「n-gram length」）在 1 到 10 个请求之间变化的结果。不同序列範围的的数量从 301（1 个请求的视窗大小）到约 780,000（10 请求的视窗大小）。根据绘图，我们观察到大量可能的序列，这些序列随着序列长度的增大而成长：随着滑动视窗大小的增加，我们看到範例中有越来越多的不同序列。平滑趋势可以由以下事实来解释：我们套用了滑动视窗（工作阶段本身可能包含许多序列）并与相对于序列长度的大量长工作阶段相结合。
鉴于可能的序列数量众多，尝试找到滥用序列简直就是「大海捞针」。

序列分析简介
下面是 API 闸道仪表板的萤幕截图，其中突出显示了序列分析：

让我们来详细了解萤幕截图中看到的新功能。
API 闸道使用前文所述的方法智慧地判定 API 使用者发出的请求序列。API 闸道按照我们称为相关性分数的指标对序列进行评分。序列分析按最高相关性分数显示前 20 个序列，我们将这些序列称为最重要的序列。高重要性序列包含可能按顺序一起发生的 API 请求。
您应该检查每个序列以了解序列的相关性分数。相关性分数较高的序列可能包含很少使用的端点（潜在的异常使用者行为）以及常用的端点（可能是良性使用者行为）。由于在这些序列中找到的端点通常一起出现，因此可以代表 API 的真实使用模式。您应将所有可能的 API 闸道保护措施套用于这些端点（速率限制建议、结构描述验证、JWT 验证和 mTLS），并与开发团队一起检查特定的端点顺序。
我们知道，客户希望在现今 API 闸道提供的主动保护之外，对其 API 明确地设定允许的行为。我们即将发布序列优先顺序规则，并实现基于这些规则阻止请求的功能。新的序列优先顺序规则将允许客户为允许的 API 请求指定确切顺序，从而提供另一种建立正面安全性模型的方法，以保护您的 API 免遭未知威胁。

如何开始使用
所有 API Gateway 客户现在都可以存取序列分析。导览到 Cloudflare 仪表板中的区域，然后按一下「安全性」索引标籤 >「API 闸道」索引标籤 >「序列」索引标籤。您将看到 API 使用者请求的最重要序列。
尚未购买 API 闸道的企业客户可以在 Cloudflare 仪表板中启用 API 闸道试用版或联络客户经理以开始使用。
下一步骤
基于序列的侦测是一项强大而独特的功能，可解锁大量识别和阻止攻击的新机会。随着我们调整了识别这些序列并将其部署到全球网路的方法，我们将在未来推出自订序列匹配和即时缓解功能。我们还将确保您拥有可执行的情报，以便向您的团队报告试图请求与原则不相符之序列的 API 使用者。

如有任何问题，欢迎透过站内简讯与我联繫。