从OWASP API Security TOP 10谈API安全

1.前言

应用程序编程接口（API）是当今应用驱动世界创新的一个基本元素。从银行、零售、运输到物联网、自动驾驶汽车、智慧城市，API 是现代移动、SaaS 和 web 应用程序的重要组成部分，可以在面向客户、面向合作伙伴和内部的应用程序中找到。从本质上讲，API 暴露了应用程序逻辑和敏感数据，如个人身份信息（PII），因此，API 越来越成为攻击者的目标。如果没有安全的 API，快速创新是不可能的。尽管更广泛的 web 应用程序安全风险 Top 10 仍然有意义，但由于 API 特殊性质，需要一份特定于 API 的安全风险列表。API 安全侧重于策略和解决方案，以了解和减轻与 API 相关的独特漏洞和安全风险。

2. API安全 top 10

2.1 API1: 2023 对象级授权失效

2.1.1 API脆弱点

对象级授权是一种通常在代码层面开发实施的访问控制机制，用于验证用户只能访问其具有权限的对象。

每个可以接收对象 ID 并对对象执行操作的 API 端点，都应该实施对象级授权检查。这些检查应验证已登录用户是否具有执行请求的操作权限。这种机制的失效通常会导致未经授权的信息泄露、篡改或破坏。仅仅将当前会话的用户 ID（例如，从 JWT 令牌中提取）与存在漏洞的 ID 参数进行比较，只能解决一小部分情况，并不足以解决对象级授权失效（BOLA）问题。

在 BOLA 的情况下，用户有意被授予对存在漏洞的 API 端点 / 功能的访问权限。违规行为发生在对象级别，通过操纵 ID 来实现。如果攻击者成功访问了本应无权访问的 API 端点 / 功能，那就是 API5:2023 功能级授权（BFLA，Broken Function Level Authorization）问题，而不是 BOLA。

2.1.2 攻击场景示例

2.1.3 预防措施

· 实施正确的授权机制，依赖于用户策略和层级结构。

· 使用授权机制检查已登录用户是否具有执行所请求操作的记录的访问权限，以及在每个使用来自客户端的输入访问数据库记录的功能中执行该检查。

· 优先使用随机且不可预测的值作为记录 ID 的 GUID。

· 编写测试以评估授权机制的漏洞。不要部署测试失败的更改。

2.2 API2:2023 用户身份验证失效

2.2.1 API脆弱点

认证端点和流程是需要保护的资产。此外，对“忘记密码 / 重置密码”的处理方式应与认证
机制一致。如果 API 存在以下情况，则可能存在安全漏洞：
• 允许凭证填充攻击，攻击者使用有效的用户名和密码列表进行暴力破解。
• 允许攻击者对同一用户账户进行暴力破解攻击，而未有验证码或账户锁定机制。
• 允许使用弱密码。
• 在 URL 中发送敏感的认证信息，如身份令牌和密码。
• 允许用户在不要求密码确认的情况下更改电子邮件地址、当前密码或执行其他敏感操作。
• 未验证令牌的真实性。
• 接受未签名或弱签名的 JWT 令牌（{"alg":"none"}）。
• 未验证 JWT 令牌的过期日期。
• 使用明文、非加密或弱哈希的密码。
• 使用弱加密密钥。
此外，如果一个微服务存在以下情况，也可能存在安全漏洞：
• 其他微服务可以在无需认证的情况下访问它。
• 使用弱或可预测的令牌进行身份验证。

2.2.2 攻击场景示例

2.2.3 预防措施

• 确保你了解了所有可能的 API 认证流程（包括移动端、Web 端、实现一键认证的深度链
接等等）。询问你的工程师是否有遗漏的流程。
• 了解您的认证机制。确保理解其使用方式和原理。OAuth 不是认证，API 密钥也不是认证。
• 在身份认证、令牌生成和密码存储方面，请使用标准的解决方案，不需要浪费精力去自创。
• 将凭证恢复 / 忘记密码的端点视为登录端点，采取防止暴力破解、限制请求速率和账户
锁定的措施。
• 要求对敏感操作（例如更改账户所有者的电子邮件地址、更改用于双因素认证的手机号码）
进行二次认证。
• 使用 OWASP Authentication Cheatsheet。
• 在条件允许的情况下，实施多因素认证。
• 实施反暴力破解机制，以减轻凭证填充、字典攻击和暴力破解攻击对认证端点的影响。
这种机制应该比 API 上常规的速率限制机制更加严格。
• 实施账户锁定 / 验证码机制，以防止针对特定用户的暴力破解攻击。
• 实施弱口令检查。
• API 密钥不应该用于用户身份验证，而应仅用于 API 客户端 API clients 的身份验证。

2.3 API3:2023 对象属性级授权失效

2.3.1 API脆弱点

当允许用户通过 API 接口访问对象时，验证用户是否具有试图访问的特定对象属性的访问权
限，这点是很重要的。
如果 API 存在以下情况，则可能存在安全漏洞：
• API 接口公开了对象的属性，这些属性被认为是用户不应读取的敏感数据。
( 原为 API3:2019 过度数据暴露 Excessive Data Exposure)
• API 接口允许用户更改、添加或删除用户本不该访问的敏感对象属性的值。
( 原为 API6:2019 批量分配 Mass Assignment)

2.3.2 攻击场景示例

2.3.3 预防措施

• 在使用 API 接口暴露对象时，始终确保用户具有访问权限才可访问所公开的对象属性。
• 避免使用通用方法，如 to_json() 和 to_string()。相反，仔细筛选您想要的返回的特定对
象属性。
• 尽量避免使用自动将客户端输入绑定到代码变量、内部对象或对象属性的功能（“API6:2019 批量分配 Mass Assignment”）。
• 仅允许客户端更改客户端有权限更新的对象属性。
• 实施基于异常通知 (Schema-based) 方式，作为额外的安全层。作为该机制的一部分，
定义和执行所有 API 方法返回的数据。
• 根据接口的业务 / 功能需求，将返回的数据结构保持最简化。

2.4 API4:2023 资源消耗不受限制

2.4.1 API脆弱点

满足 API 请求需要使用诸如网络带宽、CPU、内存和存储等资源。有时，服务提供商通过
API 集成提供所需的资源，并按请求付费，例如发送电子邮件 / 短信 / 电话呼叫、生物识别验证等。
如果 API 缺少或不恰当地设置了以下任何一个限制（例如，设置过低 / 过高），则该 API 存
在漏洞：
• 执行超时。
• 最大可分配内存。
• 最大文件描述符数量。
• 最大进程数量。
• 最大上传文件大小。
• 单个 API 客户端请求中要执行的操作数量（例如，GraphQL 批处理）。
• 单个请求 - 响应中要返回的每页记录数量。
• 第三方服务提供商的支出限制。

2.4.2 攻击场景示例

2.4.3 预防措施

• 使用容器 / 无服务器代码（如 Lambda）等解决方案，可以轻松限制内存、CPU、重新启动次数、文件描述符和进程等资源。
• 在所有传入参数和负载中定义并强制执行数据的最大大小，例如字符串的最大长度、数组中的最大元素数量以及最大上传文件大小（无论是本地存储还是云存储）。
• 在一定时间范围内限制客户端与 API 的交互频率（速率限制）。
• 根据业务需求对速率限制进行调优。某些 API 端点可能需要更严格的策略。
• 限制单个 API 客户端 / 用户执行单个操作的次数或频率（例如一次性口令验证、在无需访问一次性 URL 的情况下请求密码恢复）。
• 对查询字符串和请求体参数进行适当的服务器端验证，特别是控制响应中返回记录数量的参数。
• 为所有服务提供商 /API 集成配置消费限制。如果无法设置消费限制，则应配置计费警报。

2.5 API5:2023 功能级授权失效

2.5.1 API脆弱点

要找出失效的功能级授权问题的最佳方式需要结合应用程序中用户层级、不同角色与用户组的差异，充分分析其授权机制，并检查以下问题：
• 普通用户能否访问管理端点？
• 用户是否可以通过简单地修改 HTTP 方法（如，将 GET 请求变为 DELETE 请求）来执行他们无权访问的敏感操作（例如创建、修改或删除）？
• 属于用户组 X 的用户是否可以轻易地猜测出端点 URL 和参数（如 /api/v1/users/export_
all），并访问本该只提供给用户组 Y 的功能？不要仅基于 URL 路径来判断 API 端点是常规的还是用于管理的。开发人员可能会选择将大部分管理端点设定在特定的相对路径下，例如 /api/admins，通过其他常规端点的相关路径，如 /api/users，能够轻易地发现这些管理端点。

2.5.2 攻击场景示例

2.5.3 预防措施

在应用程序中应集成一个统一的、易于分析的授权模块，并在所有的业务功能中进行调用。
通常这种保护机制是由应用程序代码外的一个或多个组件提供的。
• 应强制默认拒绝所有访问，每个功能的访问需要明确地授权给具体的用户角色。
• 结合应用程序的业务逻辑和组织层次结构，审查 API 端点以检测功能级授权缺陷。
• 确保所有管理控制器都继承自基于用户组 / 角色授权检查的管理抽象控制器。
• 确保常规控制器中的管理功能可根据用户组和角色实现授权检查。

2.6 API6:2023 对敏感业务流的无限制访问

2.6.1 API脆弱点

创建 API 端点时，需要着重了解其所暴露的业务流程，某些业务流程比其他流程更加敏感，对这些敏感流程的过度访问可能会对业务造成损害。
以下是敏感业务流程的常见例子及与其过度访问相关的风险：
• 产品购买流程 - 攻击者可以一次性清空市场需求大的商品的库存，并以更高的价格销售（黄牛党）。
• 评论 / 发帖流程 - 攻击者可以对系统进行“刷屏”、“灌水”。
• 预订流程 - 攻击者可以预订所有可用时间段，从而阻止其他用户使用该系统。
过度访问的风险可能在不同行业和企业之间存在差异。例如，通过脚本创建帖子可能被一个社交网络认为是“刷屏”、“灌水”，而被另一个社交网络鼓励发帖。如果 API 端点中暴露一个敏感业务流程且未对端点访问做适当的限制，那么该业务流程易受攻击。

2.6.2 攻击场景示例

2.6.3 预防措施

风险缓解措施应该从以下两个方面着手：
• 业务 - 识别被过度使用可能会对业务造成损害的业务流程。
• 工程 - 选择合适的保护机制来减轻业务风险。一些保护机制是较简单易行的，而另一些则较为复杂。以下是用于降低自动化威胁的方法：
• 设备指纹识别：拒绝向未预期的客户端设备（例如无头部字段的浏览器）提供服务，这通常会迫使攻击者使用更复杂的方式，从而提高攻击成本。
• 人类检测：使用验证码或更先进的生物特征解决方案（例如击键生物识别）。
• 非人类模式：分析用户流程以检测非人类模式（例如，用户在不到一秒钟的时间内访问了“添加到购物车”和“完成购买”功能）。
• 可以考虑阻止匿名网络出口节点和知名代理的 IP 地址。确保直接被机器调用的 API（例如开发者和商户间的 API）安全、受限地访问。由于它们常常未实现所有必需的保护机制，通常会变成攻击者的易攻击目标。

2.7 API7:2023 服务器端请求伪造

2.7.1 API脆弱点

当 API 在未验证用户提供的 URL 的情况下获取远程资源时，会出现服务器端请求伪造 (SSRF)漏洞。它使攻击者能够绕过防火墙或 VPN 的保护强制应用程序将别有用心设计的请求发送到非预期的目标。应用程序开发中的现代概念使 SSRF 更常见和更危险 :
• 更常见 - 鼓励开发人员根据用户输入访问外部资源：Webhook、从 URL 获取文件、自定义 SSO 和 URL 预览。
• 更危险 – 云提供商、Kubernetes 和 Docker 等现代技术在可预测的、众所周知的路径上通过 HTTP 暴露管理和控制通道。这些通道很容易成为 SSRF攻击的目标。由于现代应用程序的连接特性，限制应用程序的出站流量也更具挑战性。SSRF 风险并非总能完全消除。在选择保护机制时，重要的是考虑业务的风险和需求。

2.7.2 攻击场景示例

2.7.3 预防措施

• 隔离网络中的资源获取机制：通常这些功能旨在获取远程资源而不是内部资源。
• 尽可能使用下列允许列表：
» 远程来源用户（例如 Google 云端硬盘、Gravatar 等）下载资源列表
» URL schemes 和端口列表
» 给定功能性可接受的媒体类型列表
» 禁用 HTTP 重定向
• 使用经过良好测试和维护的 URL 解析器来避免 URL 解析不合理引起的问题。
• 验证和检查所有客户提供的输入数据。
• 不要向客户端发送原始响应。

2.8 API8:2023 安全配置错误

2.8.1 API脆弱点

如果出现以下情况，API 可能会受到攻击：
• API 堆栈的某些部分缺少适当的安全加固，或者云服务的权限配置不当。
• 缺少最新的安全补丁，或系统已废弃。
• 启用了不必要的功能（例如 HTTP 方法、日志记录特性）。
• HTTP 服务调用链中的服务器处理传入请求的方式存在差异。
• 传输层安全性 (TLS) 缺失。
• 不向客户端发送安全或缓存控制指令。
• 跨域资源共享 (CORS) 策略缺失或配置不当。
• 错误消息中包含堆栈跟踪信息或其他敏感信息。

2.8.2 攻击场景示例

2.8.3 预防措施

在 API 的生命周期中应包含：
• 可重复的强化过程，可快速轻松地部署的适当锁定的环境。
• 审查和更新整个 API 堆栈的配置，审查应包括：编排文件、API 组件和云服务（例如 S3存储桶权限）。
• 建立持续评估所有环境中配置和设置有效性的自动化流程。
此外：
• 确保从客户端到 API 服务器以及任何下游 / 上游组件的所有 API 通信都通过加密通道(TLS) 进行，无论它是内部 API 还是面向公众的 API。
• 具体说明每个 API 允许使用哪些 HTTP 方法：应禁用所有其他 HTTP 方法（例如HEAD）。
• 基于浏览器的客户端（例如 WebApp 前端）访问的 API 至少应该：
» 实施适当的跨域资源共享 (CORS) 政策。
» 包含适用的安全标头。
» 将传入的内容类型 / 数据格式限制为满足业务 / 功能要求的内容类型 / 数据格式。
» 确保 HTTP 服务调用链的所有服务器（例如负载平衡器、反向和正向代理以及后端服务器）以统一的方式处理传入请求以避免不同步问题。
» 在适用的情况下，定义和实施所有 API 响应有效负载模式，包括错误响应，以防止异常跟踪信息和其他有价值的信息返回给攻击者。

2.9 API9:2023 库存管理不当

2.9.1 API脆弱点

API 与现代应用程序之间的分散和连接给组织带来了新的挑战，对于组织来说，不仅要对组织内部的 API 和 API 端点有良好的理解和可视化，还需要了解 API 与外部第三方之间，是如何存储或共享数据的。多个版本的 API 共存时， API 提供者需要投入额外的管理资源，同时也扩大了攻击面。
如何规避上述风险，以下问题可以帮助我们判断 API 是否存在“文档盲点”（"documentationblindspot"）：
• API 服务的用途不明确，并且下述问题没有明确的答案：
» API 服务运行在哪个环境中（例如生产环境、演示环境、测试环境、开发环境）？
» 谁应该具有 API 的网络访问权限（例如公众用户、内部用户、合作伙伴）？
» API 使用的是哪个版本？
• 没有 API 文档或 API 文档不是最新的。
• 没有为每个 API 版本制定下线计划。
• API 服务的库存清单缺失或过期。
敏感数据流的可视化和库存清单，在事件响应计划中起着重要作用，以防万一发生第三方违规事件。
以下问题可以帮助我们判断 API 是否存在“数据流盲点”（data flow blindspot）：
• 存在 API 与第三方共享敏感数据的“敏感数据流”描述，但不满足下述条件：
» 没有业务层面的正当理由或流程审批。
» 没有清单或敏感数据流的可视化流程。
» 没有对共享的敏感数据类型做深入的可视化。

2.9.2 攻击场景示例

2.9.3 预防措施

• 对所有的 API 服务进行清单管理，记录每个 API 服务的关键内容，重点关注 API 运行环境（生产、演示、测试、开发）、具有网络访问权限的人员（公众用户、内部用户、合作伙伴）以及 API 版本信息。
• 对集成服务进行清单管理，记录其中的关键内容，比如系统中的角色、数据交换情况（数据流）以及数据的敏感级别等。
• 文档化所有的 API 信息，例如身份验证、错误处理、重定向、速率限制、跨域资源共享（CORS）策略以及 API 端点信息（比如参数、请求和响应）。
• 采用开放标准自动生成 API 文档，将文档构建纳入 CI/CD 流程中。
• 仅对被授权使用 API 的人员提供 API 文档。
• 使用外部保护措施，例如针对所有暴露的 API 版本使用特定的 API 安全解决方案，而不仅仅是针对当前的生产版本。
• 避免在非生产的 API 部署环境中使用生产数据。如果无法避免，这些端点应该得到与生产环境相同的安全防护。
• 当新版本的 API 包含安全改进时，也需要对老版本进行风险分析，以确定老版本所需的缓解措施。例如，是否可以将改进的功能回溯到老版本而不影响 API 的兼容性，或者，是否需要快速停用旧版本并强制所有客户端升级到最新版本。

2.10 API10:2023 API 的不安全使用

2.10.1 API脆弱点

比起用户输入的信息，开发人员往往更信任来自第三方 API 的数据，尤其是那些由知名公司提供的 API。正因如此，开发人员趋向于使用较弱的安全标准，特别是在输入验证和净化方面。
如果 API 存在以下情况，则可能存在漏洞：
• 使用未加密的通道与其他的 API 进行交互；
• 从其他的 API 收集的数据，在处理之前没有对数据正确验证和净化，或者，在将数据传递给下游组件时没有进行适当处理；
• 盲目地跟随重定向；
• 没有限制处理第三方服务响应的资源数量；
• 与第三方服务进行交互时，没有实施超时机制。
通过满足上述安全要求，可以减少 API 的潜在漏洞，提高应用程序的安全性。