为什么 API 攻击不断增加以及如何避免它们

澳大利亚能源公司 Jemena 已经以某种形式使用 API 大约十年了。API（应用程序编程接口）的使用最近大幅增加，预计在未来几年内将增加五倍。

现在一切都是 API 优先，而不是事后的想法。

Jemena 正在使用 API 与业务合作伙伴以及面向客户的应用程序共享信息。甚至市场运营商和监管机构也在转向 API。去年，一切都在加速发展——API 化。

这给公司带来了新的安全问题。API 的特点是它们旨在提供对数据的高效访问。如果攻击者能够破坏 API，他们可能会在很短的时间内泄露大量数据。

Web 应用程序安全的传统方法侧重于防止机器人访问，但不适用于 API 安全，因为根据定义，所有 API 请求都是机器对机器的。

与其说我们面临的是机器人问题，不如说是潜在的数据泄露问题。这就是我们最担心的，不受限制地访问数据。作为一家能源公司，我们掌握了大量的个人信息。

Jemena 是一家拥有 3200 名员工的公司，为超过 35万个家庭和企业提供电力，并为超过 150 万客户提供天然气。除了通常的个人身份信息外，还有医疗敏感数据，例如哪些客户拥有生命支持设备或其他特殊要求。某些类型的数据受到监管限制，不得发送到海外，或者只能与某些已知方共享。

WAF 的有效性存在限制

该公司的 Web 应用程序受到 Web 应用程序防火墙 (WAF) 的保护，但 WAF 的功能有限。API 的配置文件与 WAF 传统上防范的内容不同，您确实期望收到大量请求，而 WAF 无法防范业务逻辑攻击。

相反，Jemena 需要的是一种安全工具，可以查看每个 API 请求的具体情况以及发送请求的机器的行为，并可以区分好机器人和坏机器人。

有很多较老的机器人拦截公司，但没有很多原生 API 安全解决方案，事情可能正在发生变化，明年市场将会发生很大变化。

去年年底，Jemena 开始寻找与公司已有的安全系统集成的解决方案，最终选择了 Salt Security。该系统采用行为方法来确保 API 安全。你必须了解数据的形状，以及请求是否符合你期望的形状。

新工具能够了解公司 API 流量的模式，找出标准请求的样子，然后查找与该模式的偏差。它位于 Web 应用程序防火墙后面，但也连接到公司的安全信息和事件管理系统 Splunk。Salt 确实有自己的仪表板。但我们并没有在 Salt 本身上花费太多时间，我们花时间在 Splunk 上查看生成的内容。

API 安全异常检测方法的一个潜在缺点是 Web 应用程序经常变化，相应的 API 流量也会变化。随着 API 数量的增加，我们将非常密切地监控情况。

Jemena 并不是唯一一家担心 API 安全性的公司，这是有充分理由的。API 极大地扩展了攻击者获取敏感数据和系统的方式。它们特别难以保护。幸运的是，包括人工智能在内的新技术开始帮助企业应对这一威胁。

最近的 API 泄露凸显了 API 风险

根据API 安全公司 FireTail 2023 年 5 月的一份报告，超过 5 亿条记录已通过易受攻击的 API 泄露，并且 2023 年有望成为 API 泄露事件创历史新高的一年。

以下是今年一些最突出的事件：

• 一月份，我们了解到丰田、梅赛德斯、宝马和其他十几个汽车品牌的 API 相关漏洞。不过，远程信息处理系统中的漏洞不仅仅暴露了客户数据。研究人员 Sam Curry在报告中写道：“如果攻击者能够发现车辆远程信息处理系统使用的 API 端点中的漏洞，他们就可以按喇叭、闪灯、远程跟踪、锁定和解锁以及启动和停止车辆，完全远程。”

• 同月，T-Mobile向 SEC 承认，黑客利用 API 窃取了 3700 万客户的数据。今年 2 月，Trustwave 研究人员发现Finsify 的 Money Lover 个人理财应用程序泄露了超过 500 万用户的电子邮件地址和钱包名称。

• 今年春天，CISA发布了有关 Nexx 车库门控制器和智能警报器的公告。超过 40,000 台设备被发现存在多个 API 漏洞，这意味着攻击者可以窃取物理地址、打开车库门和关闭警报等个人信息。

• 6 月，Patchstack 研究人员报告称，最流行的 WordPress WooCommerce 支付插件 WooCommerce Stripe Gateway 存在一个 API 漏洞，允许未经身份验证的用户查看任何订单的敏感数据，包括电子邮件和完整地址。当时，该插件拥有超过 90 万用户，其中一半使用的是存在漏洞的版本。

• 同样在 6 月，伊顿工厂的一名研究人员成功攻破了本田草坪和花园经销商电子商务平台 API，使他能够重置任何帐户的密码，并获得完整的客户信息、经销商信息、支付密钥和内部财务报告。总共有近 40,000 条暴露记录。

• 今年 7 月，JumpCloud 向超过 180,000 家企业提供基于云的目录即服务软件，“出于对正在发生的事件的高度谨慎”，更改了其 API 密钥。

这只是今年迄今为止披露的一些漏洞，不知道还有多少漏洞没有被公司披露。但我们可以猜测。Enterprise Strategy Group 对近 400 个组织进行了调查，发现 92% 的组织在过去 12 个月内至少经历过一起与不安全 API 相关的安全事件。

为什么 API 安全事件变得越来越常见

首先，将 API 暴露给网络请求会显着增加攻击面。攻击不再需要访问本地系统，而是可以远程攻击 API。

更糟糕的是，API 的设计目的是易于查找和使用，它们是“自我记录的”并且通常基于通用标准。这使它们为开发人员带来了便利，但同时也是黑客的主要目标。

由于 API 旨在帮助应用程序相互通信，因此它们通常可以访问核心公司数据，例如财务信息或交易记录。面临风险的不仅仅是数据本身。API 文档还可以让外部人员了解业务逻辑。这种洞察力可能会让发现业务流程中的弱点变得更加容易。

然后是数量问题。部署基于云的应用程序的公司不再部署具有单个进出接入点的单一整体应用程序。相反，它们由小型组件（数十个、数百个甚至数千个）组成，所有这些组件都通过 API 相互通信。

根据 Salt Security 的3 月份 API 安全状况报告，59% 的组织管理着超过 100 个 API，其中 9% 的组织拥有超过 1000 个 API，而 27% 的组织的 API 数量比去年增加了一倍多。这些 API 中的 16% 现在每月处理超过 5 亿个请求，而六个月前为 11%。每个 API 连接都是威胁参与者的潜在访问点，需要进行保护、身份验证和访问控制。

有各种标准可供选择，但实施起来可能很复杂，以 OAuth 身份验证和授权协议为例，这是 Google、Microsoft、Facebook 和其他社交身份验证主要参与者支持的开放标准。

今年春天，Salt Security 的研究人员发现实施该协议很容易出错。例如，旅游网站 Booking.com允许未经授权的人使用 Facebook 登录进入任何人的 Booking.com 帐户。此外，根据 Salt Security 3 月份的 API 安全报告，78% 的 API 相关攻击来自恶意实现看似合法身份验证的攻击者。

然后就是序列化问题。此时文件会被分成更小的部分，以便可以通过 API 进行传输。每个单独的片段本身可能是无害的，但是，当重建回完整的对象时，它可能会变成恶意软件。这导致了反序列化漏洞，允许攻击者执行任意代码。

最后，部署和更新 API 的便捷性意味着安全团队并不总是像应有的那样处于循环状态。根据 ESG 调查，75% 的组织每周甚至更频繁地更新其 API。在某些情况下，甚至可能不知道 API 的存在，这就产生了一种新型的影子 IT，影子 API，它没有得到适当的保护、监控和控制。

这是一个很难解决的问题。当我们考虑云原生开发时，开发人员不必到 IT 部门来配置他们的计算资源。他们自己建造。很多时候，他们面临着按时交付的压力。然后他们更新、更新、再更新。人们即使知道存在漏洞也会进行部署，因为他们认为可以在攻击者识别之前修复该漏洞。

这使组织面临很大的风险。当不再使用 API 时，这些风险不会消失。根据 Salt 调查，54% 的公司高度关注过时或“僵尸”API。这些连接不再使用或管理，但未正确停用，因此攻击者仍然可以利用它们。

API 安全挑战

API 生态系统的规模、复杂性和快速变化的性质带来了几个主要的安全挑战。最令人担忧的是身份验证。对于任何类型的联系来说，这都是一个基本的事情，确保它经过验证。

身份验证和授权问题占 OWASP Top 10 API 安全风险中的四项，该风险于今年 7 月更新。根据FireT a il API 数据泄露跟踪器的数据，今年迄今为止的 12 起公共 API 泄露事件中的每一起都至少涉及一个身份验证或授权漏洞。

正如 Bookings.com 的 OAuth 问题所表明的那样，身份验证很容易出错。ESG 调查显示，API 身份验证问题是企业在部署 API 时最担心的问题，88% 的受访者表示这是一个严重或中等的问题。

另一个问题是识别关键数据以及它如何在 API 生态系统中移动。建议企业找出最敏感的数据在哪里，根据哪些人可以访问该数据来优先考虑 API 安全性。不幸的是，公司通常手动执行此操作，这是一个缓慢且容易出错的过程。确实需要自动化、工具和流程来确保您可以找到 API 并了解 API 之间的关系以及它们所连接的内容。

对于内部 API 和第三方 API 来说，缺乏可见性是公司面临的一个主要问题。你无法保护你看不到的东西，将所有信息整合在一起，让他们了解他们最迫切需要解决的问题是一个大问题。

最后，公司拥有的安全工具通常不起作用。根据 ESG 调查，74% 的组织表示他们拥有强大的 API 安全计划和多种 Web 应用程序工具。59% 的组织使用 API 安全工具，57% 的组织部署了 Web 应用程序防火墙，50% 的组织拥有 API 网关，48% 的组织使用分布式拒绝服务缓解措施，42% 的组织使用爬虫程序管理工具。我们询问他们针对 API 安全采取了哪些解决方案，他们正在检查是否使用了所有这些解决方案，并表示它们是有效的。

随着企业部署更多安全工具，违规数量是否会减少？事实上，根据调查，多种API管理工具的存在是最大的安全挑战，其次是API部署缺乏可视性、第三方API库存不准确、API规范使用不一致以及开发人员缺乏在部署前对其API进行安全测试的能力。

使用多种工具，您会收到多种警报，它们是用不同的语言构建的，并且使用多种工具，因此部署、管理它们和培训人员需要更长的时间。

OWASP API 十大 API 风险

1. 对象级授权被破坏：开发人员应检查用户是否有权执行他们想要对对象执行的操作。当缺少这些检查时，该漏洞很容易被利用。它也广泛流行且易于查找，并可能导致数据丢失甚至帐户被完全接管。

2. 身份验证失效：身份验证失效的示例包括应用程序允许凭证填充或暴力攻击、允许用户使用弱密码或将敏感的身份验证详细信息（例如授权令牌和密码）嵌入到 URL 中。此漏洞很容易检测和利用，而且很常见，并且可能会导致严重的业务影响。

3. 对象属性级别授权损坏：这是另一个易于检测、易于利用且常见的漏洞。其中一个例子是预订应用程序 API，它允许主人不仅同意预订，还可以更改预订价格，向客人收取比他们预期更高的费用。这里的问题是，即使允许用户访问特定对象，他们也可能不一定需要访问这些对象的所有属性。OWASP 建议 API 返回的数据应保持在每种单独使用类型所需的绝对最小值，并且用户修改对象的能力也应保持在最低限度。

4. 资源消耗不受限制：响应 API 请求会使用带宽、CPU、内存和存储等资源。如果没有限制，成功的攻击可能会导致系统不可用（DDoS 攻击）或让公司蒙受损失。例如，密码重置请求涉及公司发送短信。攻击者可以通过脚本请求数千次密码重置，而公司将收取巨额短信费用。或者，攻击者可以利用易受攻击的 API 并使用所有可用存储空间上传大量（例如个人资料图像）。解决方案是对上传、交互和支出进行限制。该漏洞易于检测、普遍存在、利用难度中等，但对业务的影响可能会很严重。

5. 函数级别授权被破坏：这是指对特定函数的 API 调用不检查用户是否拥有正确的权限。例如，低级别用户可能能够创建具有管理权限的新用户帐户。解决方案是为每个业务功能提供基于角色的身份验证。OWASP表示，该漏洞很容易被攻击者检测、利用，而且很常见，但影响也很严重。

6. 无限制地访问敏感业务流：2023 年新增的一项，此时请求完全合法，但请求过多可能会造成损害。例如，某人可能会购买所有可用的门票，然后以更高的价格转售，用垃圾邮件淹没评论系统，或者使用预订工具预订所有可用的时段。该漏洞很容易被利用、广泛流行，并且只需要普通的技能即可检测到。

7. 服务器端请求伪造：2023 年新增功能，允许用户提供 URL，例如，他们可以输入其照片在线位置的 URL，而不是上传个人资料照片。如果攻击者提供位于公司防火墙后面的 URL，并且 API 可以访问这些资源，则用户可以利用 API 的访问权限来获取他们不允许拥有的内容。根据 OWASP 的说法，此漏洞易于检测、易于利用、很常见，并且会产生中等影响。
   基本上以授权方式命令应用程序代表我发送请求，但需要获得其自身的许可。它可用于代理请求，以便它们可以获取非常敏感的数据，或者访问云提供商的元数据服务。一个众所周知的滥用这一点的例子是 2019 年第一资本违规事件。它允许攻击者获取工作负载的会话令牌，并使用该令牌继续从自己的外部笔记本电脑模拟工作负载。它使他们能够找到包含信用卡信息的 S3 数据。

8. 安全配置错误：API 可能缺少安全补丁、系统过时或云权限配置不正确、缺少加密或包含暴露敏感信息的错误消息。根据 OWASP 的说法，这是一个广泛存在的漏洞，很容易检测和利用，并可能造成严重后果。

9. 库存管理不当：这一点与 API 可见性有关。你知道API的用途吗？它在哪里运行？它在哪个版本上？预计什么时候退休？谁应该有权访问它？API 还可能存在数据流盲点，例如不知道 API 可以访问敏感数据并将其发送给不应拥有该数据的第三方。根据 OWASP 的说法，这是一个广泛存在的漏洞，易于利用，检测难度中等，并且后果中等。

10. API 的不安全使用：2023 年新增的一项，指的是公司对外部 API 的信任程度超过应有的程度。如果第三方受到威胁，该外部 API 可能会发送错误数据，例如 SQL 注入攻击或重定向到恶意位置。根据 OWASP 的说法，这是一个常见漏洞，很容易被利用，检测难度中等，并且会造成严重后果。

API 安全的未来

企业正在寻求基于平台的 API 安全方法，以降低处理不同系统的复杂性和管理开销。这一切都与效率、降低成本和打破孤岛有关。

警报疲劳以及网络安全技能差距也正在推动公司进行整合。该行业还寻求人工智能来提高 API 安全性，包括最新的生成式人工智能。考虑以有助于提高生产力并简化手动和较低级别任务的方式应用这项技术是件好事，但不要在该技术方面发展得太快。

例如，许多公司在启用自动修复和让人工智能系统自动修复问题方面进展缓慢，因为担心它们会破坏应用程序。但现在，对于某些事情，由于对工具的信任，他们愿意进行自动修复。安全工具的改进需要时间。在此之前，我们可以预见事情在好转之前会变得更糟。

Akamai 的数据显示，2022 年 API 攻击流量创下历史新高，是上一年的 2.5 倍，下半年日攻击量经常突破 1 亿次大关。攻击者可以使用的工具越来越多。这包括人工智能。现在 31% 的攻击流量是通过 API 进行的。

此前，Akamai 曾报告称，所有网络流量的 83% 是 API。新的统计数据较低，因为它只关注攻击流量，并且由于大量 DDoS 攻击（通常不归类为 API）而导致统计数据偏低。

在攻击 API 时，攻击者可以使用的工具越来越多。这包括人工智能。他说，很难判断 API 攻击何时受到人工智能的帮助，当涉及网络钓鱼或社会工程时，这一点更为明显。我们今天还没有看到它以大规模、可见的方式被使用，但作为一个安全社区，我们不应该对此感到太多安慰，因为浪潮即将到来。

与此同时，Salt Security 的 3 月份 API 安全报告显示，针对公司 API 的独特攻击者数量猛增。截至 2022 年初，该公司追踪到了 123 名攻击者。到 6 月，这一数字已增至 497 名。然后到了 12 月，就有 4842 名独特的攻击者被追踪。

Salt Security 也进行了调查，发现该公司90%的情况下都存在API安全漏洞，其中50%是严重漏洞。由于这些挑战，59% 的公司表示，由于 API 安全问题，他们已经放慢了新应用程序的部署速度，48% 的公司表示 API 安全性现在已成为 C 级讨论主题。

原文来源：网络研究院

“投稿联系方式：孙中豪 010-82992251 [email protected]”

原文始发于微信公众号（CNCERT国家工程研究中心）：为什么 API 攻击不断增加以及如何避免它们