API滥用检测
API非常重要。在整个2000年代，他们形成了流行的Web服务的骨干，帮助互联网变得更加有用和可访问。在2010年，API在我们的生活中发挥了更大的作用，允许个人设备与数字世界进行沟通。我们的许多日常活动，如使用Rideshare服务和支付窗格，取决于这种形式的现代通信。现在我们正在接近一个后大流行的世界，其中API将比以往任何时候都更加重要。
不幸的是，随着任何技术的增长，它的表面积都会滥用。 API也不例外。竞争骑士服务可能会通过API监控彼此的价格，提高价格战，浪费数字资源。或者咖啡饮用者可能会操纵拿铁折扣的API。有些公司拥有数千家API - 包括他们甚至不知道的那些API。 CloudFlare可以帮助解决这些问题。
在进一步之前，重要的是解释为什么我们需要解决API的解决方案。传统的安全工具，包括速率限制和DDOS保护，可以非常有用。但这些方法并没有独自行动。我们可能会限制特定的API端点，但我们如何选择适当的阈值？难以在尺度上以造成问题来执行此操作。 API可能会被分布式攻击（低于阈值）击中，或者可能会看到合法流量增加（超过阈值）。
其他人建议在API端点上部署机器人管理。在许多情况下，这是有效的，并且增加了一定程度的保护，特别是如果API是由浏览器使用的（作为Web应用程序的一部分）使用。但机器人管理旨在在人类中找到糟糕的演员。这些演员通常使用自动化，而人类通常使用浏览器，因此区分有点明确。但API存在不同的问题。 API是自动的，因此任何解决方案都必须在其他机器人中找到不良机器人。我们必须区分良好和自动化的交通。
为了解决API问题，我们必须制定一个意图的衡量标准 - 几乎就像采访每个请求确定其目标。我们必须纯粹基于间接数据来回答以下问题：
同时，虽然速率限制等工具可以处理二进制问题（例如，“具有此IP超过200个请求？”），但API问题要求更主观的仲裁符号。它要求我们检查API的目的，并根据我们发现的内容定义合理的限制。它还要求我们找到一个新的地面真理来源。当我们建立机器人管理时，我们可以通过发出挑战确认请求或自动化。 API涉及通过解决挑战来证明其合法性的自动化服务。
经过几个月的整个问题，我们很高兴能够先查看我们的解决方案。它有几个部分......
我们的一些用户告诉我们他们无法跟踪他们的API。在我们尝试保护这些端点之前，我们需要将它们映射出来并理解攻击表面区域。我们称之为“API发现”。
发现过程从简化开始。大型网站可能有数千名的API，但很多呼叫看起来相似。考虑以下两条路径：
在此示例中，“237”和“415”是客户标识符。这两条路径都提供了相同的目的 - 它们允许用户登录其帐户 - 但它们并不相同。所以我们映射路径并立即折叠它们：
请注意我们如何删除客户标识符。我们的系统可以检测API的变化部分，允许我们识别两个路径作为同一个路径。我们通过记录每个端点的基数来执行此操作。例如，我们最初可能发现观察到700个不同的字符串来代替星号。 “237”和“415”只是其中的两个可能性。然后我们使用无人监督的学习来选择阈值（在这种情况下，让我们说30）。由于我们注意到这条道路的超过30个变体，因此我们将客户标识符识别为变量并折叠路径。此过程称为“路径标准化”。
API Discovery是许多安全产品的构建块。但在其核心，该技术是关于生产简单，值得信赖的API地图。这是您可能发现的一个小样本：
想象一下，这个列表缩放到数百个，如果不是数千个端点。有些人会很明显（希望登录端点是预期的！），但其他人可能是一个惊喜。最终地图将有助于识别每个端点引用的变量或令牌。
现在我们已经发现了API，我们可以开始寻找虐待。我们的第一个方法处理体积异常。换句话说，我们对达到每个路径的频率进行了解的猜测，并设置了一些阈值以管理滥用。这是一种自适应速率限制的形式。
考虑体育网站的API路径/更新分数。您可能猜测这是什么 - 它通常会给游戏的最新分数获取，这可能会每秒多次发生。我们可能部署无监督的学习并设置正常使用的高阈值。或许为特定IP，用户代理或其他会话标识符每分钟的150个请求。
但同样的运动网站可能需要用户拥有账户。在这种情况下，同一域上存在单独/重置密码API。没有体育风扇会在检查得分后重置密码，因此该路径可能具有较低的阈值。无监督学习的美丽（以及我们的滥用检测形式）是我们映射您的网站，为每个API开发单独的基线，并尝试预测所需请求的意图。如果我们看到150突然尝试重置密码，我们的系统会立即怀疑账户收购。
理解为什么交通班次时也很重要。例如，当由于NBA决赛而飙升时，我们不应该阻止运动流量。虽然/更新分数端点可能会暂时查看更多使用，但CloudFlare会识别更大的上下文并更改任何相关阈值。我们只想在个人滥用终点时减轻。
我们的团队经常将瑞士奶酪模型应用于安全性。这种方法已用于医疗保健，物理安全和许多其他行业，但这个想法很简单。任何一层防御都会有几个洞 - 但堆叠在彼此相邻的独特防御（或切片的奶酪）可以提高整体安全。
在互联网安全世界中，我们称之为“深度防守”。 API首先受到CloudFlare的安全套件（DDOS等）保护。第二层使用体积检测（上文描述）。但第三层与我们之前所做的任何事情完全不同：它是序贯异常检测。我们希望这可以大大改变API景观。
这是它的工作原理。像往常一样，我们首先通过运行路径规范化来查找有限组状态。在一次测试中，该过程将大约10,000个态减少到仅为60，大量简化API问题。然后，我们使用Markov链来构建转换矩阵，这是所有州的地图以及它们通常导致的地方。我们通过为每个转换分配概率来完成。
最终结果？我们可以在网站上概念上的动作，这可能包括以下步骤：
这看起来像试图登录的有效用户。再次，我们使用无人监督的学习来检测像这样的流量，但我们的方法也检测到异常值。在这种情况下，我们发现1→2→3是逻辑流量，但如果有人直接到达步骤3，那么怎么了？我们可能会像异常一样向该请求标记。
这种依赖于马尔可夫链的方法非常有效。考虑将单个节点添加到链中：显然，链本身线性缩放。转换矩阵，它映射到所有可能的节点关系，呈指数级。但我们发现大多数这些关系都没有行使。在实践中，没有人追求符号→上传→Auth等复杂的路径。更常见的过渡，可能看起来像登录→更新 - 得分→注销，只占我们测试中所有转换的2％。我们可以通过忽略未使用的转换来有效地存储矩阵。
这包装了我们序贯异常检测的概述。这是我们瑞士奶酪模型中的最后一层，就像体积的方法一样，它利用了随着时间的推移更新的基线。
API滥用检测非常多样。虽然我们为通用API使用创建了这项技术，但有一些使用案例值得突出显示。
第一个是移动应用程序的机器人管理。虽然我们的机器人管理解决方案为许多应用程序工作得很好，但API滥用检测明显更有效。这是因为移动设备经常依赖API。虽然他们的请求遵循缓慢，故意的人类用户的步伐，但移动应用程序消耗API端点，并且可能会出现自动化。这些应用程序不提供网站所做的相同的导航自由。但我们可以将此与我们的优势一起使用：合法用户遵循基于先前状态的可预测序列，我们现在能够使用API滥用检测验证。
其他公司开发了移动SDK，以接近API滥用。但是SDK庞大，难以整合，有时无效。此客户端方法也容易受到篡改。它执行客户端软件的身份验证，但不能检测到任何实际的滥用行为。任何可以提取客户端证书的人都可以立即绕过机器人保护。我们相信我们可以在没有任何类型的SDK的情况下保护移动应用程序 - 只需通过在移动端点上部署API滥用检测。
此外，许多API端点都拥挤。不是每个人都可以识别他们的“好”API / BOT流量，这意味着正面安全模型可能无法正常工作。与旋转用户代理商或无法对齐信号的合作伙伴合作的公司尤其如此。我们的方法完全避免了这头疼。我们自动构建API端点的地图，开发基准，并检测滥用。
您有一个需要API滥用检测的网站吗？ 您想尝试对您的移动应用程序的下一代机器人管理吗？ 请通过联系您的帐户团队，告诉我们。 我们很高兴在未来几个月带来这些模型。 安全周安全API机器人API滥用检测
