所有文章 > API安全 > API 安全性的全面入门指南
API 安全性的全面入门指南

API 安全性的全面入门指南

在构建应用程序时,您需要一个与其通信的接口,它可以是用户界面(UI),用于用户与您的应用程序交互,也可以是应用程序编程接口(API),用于其他系统与您的应用程序交互。

从根本上讲,API 提供的服务提供了其他系统可用于请求操作和交换信息的方法和数据格式。当其他系统向 API 发送请求以获取特定数据或执行操作时,API 会处理这些请求(可能涉及访问数据库、资源甚至其他 API),并返回包含数据的响应,供其他系统处理。

在当今世界,API 已成为数字领域的基本组成部分,因为通过 API 提供服务的提供商和消费者数量在急剧增长。以下现实世界的情况可以说明这一点:

  • 全球有大量电子商务平台通过集成 Stripe、PayPal、Square 等 API 支付网关来处理支付。
  • 大量应用程序通过其 API 与 Facebook、Instagram 或 X(前 Twitter)集成,以便用户共享内容和信息。
  • 或者通过 API 实现移动应用程序、电视应用程序、汽车应用程序、家庭自动化应用程序等之间的无缝连接。

为什么保护 API 如此重要?

随着 API 的使用范围不断扩大,互联数字系统的复杂性也不断增加,攻击面也随之扩大,这自然会导致 API 遭受网络攻击的风险增加。显然,创建具有强大安全性的可靠 API 以保护它们和整个数字生态系统的需求日益增加。

如果安全性实施不充分,API 就会带来重大风险,因为攻击者可能会利用漏洞造成严重后果。例如:

  • 损害数据的完整性。
  • 访问您的数据,导致数据泄露。
  • 控制关键功能并危及您的服务运营。

当然,其后果可能远远超出单个 API,因为 API 的漏洞会对使用它的客户端和 API 所使用的系统产生多米诺骨牌效应,从而危及整个生态系统的安全。

最严重的 API 威胁

OWASP API 安全

为了提高人们对最严重的 API 安全威胁的认识,开放全球应用程序安全项目 (OWASP) 调查并发布了最严重的 API 安全风险列表。您应该查看OWASP 十大 API 安全风险,以掌握最严重的威胁并相应地保护您的 API。

影响 API 的安全问题不止于此,因为这不是一份详尽的清单。

尽管如此,为了方便起见,这里还是列出了 OWASP 2023 年十大 API 安全风险:

OWASP 2023 年十大 API 安全风险

风险描述
1:2023 对象级授权损坏API 往往会暴露处理对象标识符的端点,从而创建对象级访问控制问题的广泛攻击面。每个使用用户 ID 访问数据源的函数都应考虑授权检查。
2:2023 身份验证失败身份验证机制通常实施不当,导致攻击者能够窃取身份验证令牌或利用实施缺陷暂时或永久地冒充其他用户的身份。系统识别客户端/用户的能力一旦受损,整个 API 安全就会受到损害。
3:2023 损坏的对象属性级别授权此类别结合了 API3:2019 过度数据泄露和 API6:2019 – 批量分配,重点关注根本原因:对象属性级别的授权验证不足或不当。这导致信息泄露或被未经授权的各方操纵。
4:2023 不受限制的资源消耗满足 API 请求需要网络带宽、CPU、内存和存储等资源。其他资源(如电子邮件/短信/电话或生物识别验证)由服务提供商通过 API 集成提供,并按请求付费。成功的攻击可能导致拒绝服务或运营成本增加。
5:2023 功能级别授权损坏具有不同层次、群组和角色的复杂访问控制策略以及管理功能和常规功能之间的不明确划分往往会导致授权漏洞。通过利用这些问题,攻击者可以访问其他用户的资源和/或管理功能。
6:2023 不受限制地访问敏感业务流易受此风险影响的 API 会暴露业务流程(例如购买门票或发表评论),但无法弥补过度自动化使用功能可能对业务造成的损害。这不一定是实施错误造成的。
7:2023 服务器端请求伪造当 API 在未验证用户提供的 URI 的情况下获取远程资源时,可能会发生服务器端请求伪造 (SSRF) 漏洞。即使受到防火墙或 VPN 的保护,攻击者也可以强迫应用程序将精心设计的请求发送到意外目的地。
8:2023 安全配置错误API 及其支持系统通常包含复杂的配置,旨在使 API 更加可定制。软件和 DevOps 工程师可能会忽略这些配置,或者不遵循有关配置的安全最佳实践,从而为不同类型的攻击打开大门。
9:2023 库存管理不当API 往往比传统的 Web 应用程序暴露更多的端点,因此正确且更新的文档非常重要。主机和已部署 API 版本的正确清单对于缓解诸如弃用的 API 版本和暴露的调试端点等问题也很重要。
10:2023 API 的不安全使用开发人员往往更信任从第三方 API 收到的数据,而不是用户输入,因此倾向于采用较弱的安全标准。为了入侵 API,攻击者会攻击集成的第三方服务,而不是直接入侵目标 API。

API 安全基础知识

本节重点介绍 API 安全的最基本原则,您应将其视为为设计和实施 API 建立安全基础的基石。

授权和访问控制

授权和访问控制决定用户或系统可以访问哪些操作或资源:

  • 授权– 授权定义授予经过身份验证的实体的策略和权限。精心设计的授权系统可确保用户或系统只能访问您希望他们访问的资源和功能。
  • 访问控制– 访问控制强制执行授权策略,规定如何根据预定义规则授予或拒绝权限。这涉及以下机制:
    • 基于角色的访问控制 (RBAC) – 用户或系统具有关联角色,该角色定义了 API 内的访问权限。
    • 基于属性的访问控制 (ABAC) – 在这种情况下,策略是根据与用户、系统甚至其他特征直接相关的特定特征来实施的。例如,部门、位置或一天中的时间。这种机制也可以称为基于策略的访问控制 (PBAC) 或基于声明的访问控制 (CBAC)。

令牌是实现授权的常用方法,在需要身份验证的设置过程中获取。它们将携带有关授权策略的信息,并在授予用户或系统访问权限之前由 API 进行验证。

最常见的令牌类型是:

  • API 密钥– 向 API 发送的用于识别客户端的字母数字令牌。通常,API 密钥授予对 API 可以执行的每个操作的完全访问权限。它通常用于服务器到服务器的通信或以简单性为优先的场景。
  • 开放授权 (OAuth) – 向 API 发送请求以代表客户端发出请求而不暴露其凭据的令牌。令牌包含允许对授予的访问级别进行细粒度控制的信息。这是一个更强大的框架,在涉及用户的场景中表现出色。通常使用两个令牌来实现 OAuth:
    • 访问令牌– 在请求中发送的令牌。访问令牌可能会过期(可选)。
    • 刷新令牌——当前访问令牌过期时发送的请求新访问令牌的令牌。 
  • JSON Web 令牌 (JWT) – JWT 是一种紧凑且自包含的令牌,在请求中发送到 API 以识别客户端。该令牌包含确定身份和访问范围所需的数据的 base64 编码版本。它包含三个部分:指定令牌类型和签名算法的标头、带有声明或断言的有效负载以及用于完整性验证的签名。

JWT 提供了一种安全传输信息的多功能方式,在复杂的环境中特别有用。

根据您的 API 所需的安全措施实施一种或多种机制的组合。

数据加密

通过加密数据,防止攻击者读取客户端和 API 之间交换的数据(传输中的数据)和存储的数据(静态数据)。

  • 传输加密– 这是通过 HTTPS 等协议实现的,这些协议会在传输过程中自动加密数据,使任何观察网络的人都无法理解。例如,有人试图在公共 Wi-Fi 上窃听网络。
  • 静态加密– 这涉及保护存储在支持 API 的磁盘或数据库中的数据。如果未经授权访问服务器或数据中心,攻击者将无法解密数据。

选择强大的加密算法、确保密钥安全以及使用经过验证的加密库是全面数据保护策略的关键方面。无论是信用卡详细信息、用户凭据还是敏感的业务信息,传输和静态加密的应用都可以确保您的 API 以机密性和弹性处理关键数据,以抵御潜在攻击。

输入验证

保护 API 不仅限于授权、访问控制和加密。另一个需要考虑的重要方面是输入验证,以防止通过将恶意代码注入应用程序来利用漏洞进行注入攻击。

例如,如果未充分验证 API 请求中的输入(例如查询参数),则可能成为注入攻击的潜在入口点。通过验证输入数据,您可以确保其符合预期的格式和标准,从而防范注入漏洞(例如 SQL 注入)。

定义并实施严格的输入验证策略,并确保您选择高度安全且完善的库。

API 安全性的最佳实践

本节概述了 API 安全的最佳实践列表,其中包含一些原则和可操作的策略,可增强 API 抵御安全威胁的弹性和可靠性。

前三项最佳实践证实并强调了我们在讨论 API 安全基础时提到的安全基础的重要性。但是,您还必须研究其他最佳实践并考虑应用它们,因为它们将全面提高您的 API 安全性。

授权和访问控制

根据预定义的角色或属性实施精细控制并限制对 API 资源的访问。这可确保用户或系统仅具有必要的权限。

遵守最小特权原则,确保仅向用户或系统授予执行特定任务或功能所需的最低访问权限。这样,您可以显著降低未经授权的访问和数据泄露的风险。

数据加密

使用 HTTPS 等加密协议来保护传输中的数据并实施加密。在与 API 和应用程序的所有通信中使用 TLS(传输层安全性)。TLS 可确保传输过程中数据的机密性(无法读取)、完整性(无法更改)和身份验证(我们期望的来源)。

对于静态数据,请选择成熟的加密算法和工具来加密磁盘和数据库。还请考虑对特别敏感的数据进行标记化,这会将数据替换为对攻击者毫无意义的标记,只有授权方才能将这些标记映射回原始数据。

输入验证

仔细检查并过滤请求中提供的数据,以防止注入漏洞。实施彻底的输入验证,以确保数据符合预期的格式和标准。

速率限制和节流

实施机制来控制 API 请求的频率和数量。速率限制(也称为节流)有助于降低滥用和拒绝服务攻击的风险。这可以通过应用程序来实现,需要花费大量的实施时间。不过,它可能会让您对特定情况进行精细控制,甚至将速率限制与应用程序概念或逻辑联系起来。

或者,您可以使用 API 网关/防火墙,这通常更简单,并提供更完整的解决方案,以最小的努力保护整个 API(参见最后的最佳实践)。

日志记录和监控

建立系统化的日志记录实践并实施监控工具,以检测和应对异常活动或潜在的安全事件。定期检查日志并针对可疑行为设置警报。确保您的日志始终能够回答以下问题:谁?何时?什么?

定期安全审计和测试

定期进行安全审计,包括在开发生命周期内进行渗透测试和代码审查,以识别和解决潜在漏洞。积极主动地应对新出现的威胁和不断发展的安全标准。

API 版本控制和生命周期管理

实施版本控制,以便在对 API 进行更改时实现平稳过渡。建立明确的生命周期管理实践,以淘汰弃用的版本并保持兼容性。

安全的第三方集成

与其他 API 集成会增加对第三方提供商的依赖,以及确保系统安全的复杂性和挑战。从这个意义上讲,在与第三方 API 集成之前充分评估其安全风险并规划实施阶段所需的缓解措施至关重要。

仅分享必要的信息

仅共享必要信息的原则规定,API 在执行特定交易或交互时应披露最少的信息。这一原则对于减少敏感数据的暴露和限制潜在的攻击媒介至关重要。这一原则也称为最少披露原则。

API 网关

最后但并非最不重要的一点是,考虑将 API 网关作为管理和保护 API 生态系统的中心点,并强化上面描述的一些最佳实践。

API 网关提供多种功能:

  • 授权– 它可以包括对 API 密钥、OAuth、JWT 和其他协议的支持。它还可以实施授权策略来控制对特定 API 资源的访问,确保只有授权用户或应用程序才能访问某些端点。
  • API 密钥管理– 处理 API 密钥或令牌的生成、分发和撤销,确保安全访问 API 并有效管理访问凭据。
  • 安全协议和加密– 强制执行 HTTPS 等安全协议,以确保数据加密且安全。管理 TLS 终止,减轻各个 API 加密的复杂性。
  • 输入验证– 验证传入的请求以防止常见的安全威胁,如 SQL 注入、参数篡改和恶意上传。
  • 请求和响应转换– 修改传入请求和传出响应以遵守安全性、合规性或数据格式要求。
  • 速率限制和节流– 保护 API 免受过多流量的影响。 
  • 日志记录和监控– 记录 API 流量,这对于调试、审计和安全分析非常有用。还提供实时监控和分析以跟踪 API 性能、流量模式和安全问题。
  • API 版本和兼容性– 支持旧版本和新版本,确保向后兼容性和 API 版本之间的平稳过渡。
  • 路由和请求转发– 根据预定义的规则和配置将传入的请求路由到适当的后端服务或微服务。
  • 负载平衡– 优化资源利用率并增强整体 API 可靠性。
  • 缓存– 通过减少后端服务器的负载并最小化响应时间来提高 API 性能。
  • 可扩展性和高可用性– 水平扩展以处理增加的 API 流量,并可部署在多个区域或数据中心以确保高可用性和灾难恢复。
  • 跨源资源共享 (CORS) – 强制执行 CORS 策略来控制哪些域可以访问 API,帮助防止跨源请求攻击并确保跨源 API 请求的安全。
  • 策略执行和可扩展性– 支持自定义安全策略的执行,并与安全插件和扩展集成,以适应不断变化的安全威胁和合规性要求。

测试 API 安全性

API 安全测试是应对不断演变的威胁的基础。如果定期系统地进行测试,您肯定会提高 API 抵御潜在威胁的稳健性。

API 安全测试的类型

在 API 安全方面,可以采用各种测试方法来发现漏洞并确保更全面地识别 API 中的漏洞。

以下是一些需要考虑的测试类型的列表:

  • 授权测试– 评估 API 授权机制(例如 API 密钥、OAuth、JWT)的有效性,并检查授权策略和控制是否正确实施和执行。此外,验证 API 令牌、密钥和凭据的安全生成、存储和撤销,以防止未经授权的访问。
  • 数据安全测试– 评估 API 对敏感数据的处理。这包括验证数据加密、适当的数据屏蔽以及防止数据泄露的措施。
  • 渗透测试– 对 API 进行受控攻击,以识别漏洞并评估其对现实威胁的抵抗力。渗透测试人员模拟 SQL 注入、服务器端请求伪造 (SSRF) 等攻击。
  • 模糊测试– 通过向 API 提供无效或意外的输入来检测潜在的安全漏洞。模糊测试旨在识别与输入验证、数据解析和错误处理相关的漏洞。
  • 错误处理和日志测试– 评估 API 的错误处理机制和日志记录实践。查找通过错误消息泄露的潜在信息,并评估 API 处理恶意或意外输入的能力。
  • 合规性测试——确保 API 符合行业特定的法规和标准,例如 GDPR、HIPAA 或 PCI DSS,这些法规和标准规定了如何保护敏感数据。
  • 负载测试– 分析 API 在高流量条件下的行为,以确定其容量和限制,确保 API 能够处理增加的用户负载,而不会降低性能或安全性。更重要的是,它还有助于防止拒绝服务 (DoS) 和分布式拒绝服务 (DDoS) 攻击的情况。 

测试工具和框架

选择正确的工具和框架会显著影响 API 安全测试的有效性。以下是一些必备工具和框架的列表:

  1. Probely DAAST(动态 API 和应用程序安全测试) ——一款强大且可扩展的安全测试工具,用于识别 Web 应用程序和 API 中的安全漏洞。其广泛的漏洞和合规性测试、配置和集成功能、自动化和详细报告使其成为 API 安全的宝贵资产。
  2. OWASP ZAP(Zed Attack Proxy) ——一种多功能开源安全测试工具,广泛用于 Web 应用程序和 API 安全评估。它提供自动扫描程序,用于识别常见漏洞,以进行全面测试。
  3. Burp Suite – 用于渗透测试的安全测试工具,具有 API 测试的特定功能。它包括扫描和分析 API、拦截请求和响应以及识别安全漏洞(如 SSRF 或 SQL 注入)的功能。
  4. Postman – 一款简化测试流程的 API 开发和测试工具。它允许测试人员创建和管理 API 请求、自动化测试和监控响应。虽然它主要是一种开发工具,但由于其易用性和自动化功能,可以有效地用于安全测试。
  5. Jenkins – 一种常用于持续集成和持续交付 (CI/CD) 管道的自动化服务器。虽然 Jenkins 本身并不是一个测试工具,但可以通过将其与其他安全测试工具和脚本集成来自动化 API 安全测试。
  6. SwaggerHub Explore – 一种基于云的工具,用于测试使用 Swagger 或 OpenAPI 规范记录的 API。它有助于发送请求并在开发过程中发现潜在的安全问题。

根据您的安全测试目标、被测试 API 的性质以及测试团队的专业知识选择正确的工具和框架。

保障数字世界的门户安全

API 安全不应被视为奢侈品,而应被视为必需品。由于 API 已成为我们日益互联的数字环境中现代应用程序和服务不可或缺的一部分,因此需要采取保护措施来保护它们免受数字世界中众多威胁和恶意行为者的侵害。

如果没有适当的 API 安全性,敏感数据和功能的网关将完全被解锁,任何人都可以轻易进入,有时甚至没有人注意到,直到为时已晚。

我们希望本指南能为您提供一个很好的介绍,让您知道您应该担心什么,以及如何开始关注这些网关的安全性。即使您认为自己受到了保护,那些恶意行为者的技巧和狡猾程度也不容小觑,而且随着时间的推移,他们的技术水平将越来越高。

文章来源:A Comprehensive Intro Guide to API Security

#你可能也喜欢这些API文章!