OWASP 十大 API 安全风险概述和最佳实践

完善的 API 安全措施必不可少，如此可以保护数据免受未经授权的访问、操纵或泄露，从而确保隐私且维持用户和利益相关者的信任，同时还可以确保 API 的机密性、完整性和可用性。API 安全最佳实践包括以下内容：

• 实施强身份验证和授权。强制执行适当的授权检查，确保经过身份验证的客户端具有访问特定资源或执行某些操作的必要权限。使用精细访问控制来限制对敏感 API 端点或数据以及相关对象和功能的访问。
• 验证输入和输出编码。验证和净化从 API 客户端收到的所有输入，防止注入攻击，并对输出进行适当编码，以防止执行恶意脚本。
• 使用安全通信。采用安全协议在 API 客户端和服务器之间传输数据，并对传输中和静态的敏感信息进行加密，确保数据的机密性和完整性。
• 实施速率限制和节流。对 API 客户端在指定时间范围内可以发出的请求数量进行限制，防止过度使用或进行未授权访问尝试，例如分布式拒绝服务 (DDoS)和暴力破解攻击。
• 定期进行安全测试和审计。定期进行安全评估、渗透测试和代码审查，从而识别和解决 API 中的潜在漏洞，并进行安全审计，以便检测弱点并确保符合行业标准和要求。由于 API 与底层框架和库之间存在相互依赖性，务必要重视这一点。
• 强制执行架构和协议合规性。通过 OpenAPI 规范自动创建和强制执行主动的安全模型，这是确保一致安全策略的重要工具。
• 动态发现并持续评估 API。API 激增会导致难以明确所有 API 的位置或难以维护所有 API，包括影子 API。安全控制需要使用零信任和最低访问权限范式不断清点和保护 API，从而缓解第三方相互依赖项的不可预见风险。
• 全面的威胁检测。API 受制于并需要防范各种威胁，包括漏洞利用、错误配置、Bot、欺诈和滥用。

2023 年 OWASP 十大 API 安全风险旨在加强对常见 API 安全漏洞的认识，并帮助开发人员、设计师、架构师、经理和其他参与 API 开发和维护的人员采用一种主动的方式来保护 API 的安全。

2023 年 OWASP 十大 API 安全风险具体如下：

1. 对象级别授权失效（Broken object level authorization）。当应用未能在对象或数据级别正确强制执行访问控制，从而允许攻击者操纵或绕过授权检查，并对应用中的特定对象或数据授予未授权访问权限时，就会出现此安全漏洞。这可能是由于授权检查实施不当、缺乏适当的验证或绕过访问控制所致。接收对象 ID 并对对象执行任何操作的每个 API 端点都应实施对象级授权检查，从而验证登录的用户是否有权对请求的对象执行所请求的操作。
2. 身份认证失效（Broken authentication）。通常是 API 中的身份认证机制发生实施不正确的问题，允许攻击者获得对用户帐户或敏感数据的未授权访问，或执行未经授权的操作。通常是由于身份认证流程实施不当或配置不当、弱密码策略、会话管理缺陷或身份认证工作流程中的其他弱点所致。
3. 对象属性级别授权失效（Broken object property level authorization)。当 API 未能在对象属性级别正确实施访问控制和授权检查时，就会发生此威胁。如果 API 端点会暴露属于敏感信息且不得由用户读取的对象属性，则容易受到上述攻击，这种漏洞有时被称为过度数据暴露。API 端点如果允许用户更改、添加或删除敏感对象属性的值，则也容易受到上述攻击，这种漏洞有时被称为批量分配。
4. 未受限制的资源消耗（Unrestricted resource consumption）。这种攻击也称为资源耗尽，涉及利用 API 实施中的弱点，故意消耗过多的资源（如 CPU、内存、带宽或其他系统资源）。这种拒绝服务 (DoS) 会降低 API 或底层系统的性能或可用性，并可能导致停机。
5. 功能级别授权失效（Broken function level authorization）。当 API 未能在功能或操作级别正确强制执行授权检查，从而允许攻击者访问未经授权的功能时，就会发生此威胁。由于现代应用可以定义许多类型的功能角色和组，并涉及攻击者可以操纵的复杂用户层级，因此很难实施正确的授权检查。
6. 敏感业务访问无限制（Unrestricted access to sensitive business flows）。当 API 缺乏适当的访问控制或授权检查时，就会发生此攻击，从而使攻击者能够自动访问由 API 支持的敏感业务流程。这些业务流程可以为大批量购买货少高价的产品（如门票或运动鞋）提供支持，而这些产品可以在二级市场上以高于原价的价格转售。攻击者常会使用精密的自动化工具包重新调整攻击，如果目标的 Web 应用受到反自动化防御的充分保护，则他们可能会改弦易辙，向 API 背后的业务逻辑下手。
7. 服务端请求伪造（Server-Side Request Forgery，即 SSRF)。当攻击者识别出易受攻击的 API 端点（接受用户提供的 URL 或对外部资源执行服务器端请求）时，就会产生此漏洞。攻击者会特制恶意请求，指定被攻击者视为攻击目标的内部资源或系统的 URL。在未辨别恶意请求的情况下，服务器就会对指定的 URL 执行服务器端请求，可能会暴露敏感信息或服务。
8. 安全配置错误（Security misconfiguration）。攻击者会试图查找未修补的缺陷、常见端点、使用不安全的默认配置运行的服务，或未受保护的文件和目录，以获得对 API 的未授权访问。当 API 堆栈的任何级别（从网络到应用级别）缺少适当的安全强化，或者云服务上的权限配置不当时，都可能导致此漏洞。错误配置会影响 Web 应用和 API，并且随着架构不断分散并分布在多云环境中，风险也与日俱增。
9. 存量资产管理不当（Improper inventory management）。随着时间的推移，API 可能会发生变化和更新，但过时或不安全的 API 版本可能会保留在生产环境中，或者较旧的端点可能会在未修补的状态下运行或使用较弱的安全要求，从而增加安全漏洞风险。由于缺乏适当的库存管理，因此很难跟踪正在使用的版本、过时或弃用的版本以及已解决的漏洞。影子和僵尸 API 存在极大的风险，而这也凸显了持续发现和自动保护的重要性。
10. API 的不安全使用（Unsafe consumption of APIs）。开发人员倾向于信任从第三方 API 接收的数据，特别是从知名公司提供的 API 接收的数据，并且在输入验证和清洗或传输安全性方面，会对这些数据采用较弱的安全要求。当通过不安全的协议访问 API 或未使用适当的加密机制时，也可能发生不安全的消耗使用情况，从而导致窃听、数据拦截和对敏感信息的未授权访问。