摘要: 2023年6月5日，OWASP正式发布了2023版API安全Top 10列表。首版 OWASP API Security Top 10 发布于2019年，今年2月时，OWASP曾发布过一个候选版（Candidate），现在终于等到了正式稳定版（stable v...
2023年6月5日，OWASP正式发布了2023版API安全Top 10列表。首版 OWASP API Security Top 10 发布于2019年，今年2月时，OWASP曾发布过一个候选版（Candidate），现在终于等到了正式稳定版（stable version）。
该列表与2019版有许多相似之处，但也进行了一些重组/重新定义并引入了一些新概念。威胁和风险在几年内都不会发生剧烈变化；但它们在进化，我们对它们的理解也在进化。2023 年的清单证明了这一点——与其说是新清单，不如说是对现有清单的改进。
以下让我们看看这份清单：
API1:2023 - Broken Object Level Authorization 对象级别授权失效
描述：APIs往往公开处理对象标识符的端点，从而创建了一个广泛的攻击面，存在对象级访问控制问题。在使用用户提供的ID访问数据源的每个功能中，应考虑对象级授权检查。API倾向于公开处理对象标识符的端点，从而造成对象级访问控制问题的广泛攻击面。在使用来自用户的ID访问数据源的每个函数中，都应该考虑对象级别授权检查。
如何预防：
实现依赖于用户策略和层次结构的适当授权机制。
在使用客户端输入访问数据库中的记录的每个函数中，使用授权机制检查登录的用户是否有权对记录执行请求的操作。
偏向使用随机和不可预测的值作为记录ID的GUID。
编写测试以评估授权机制的漏洞。
API2:2023 - Broken Authentication 认证失效
描述：身份验证机制的实现往往不正确，使攻击者能够破坏身份验证令牌，或利用实现缺陷临时或永久地采用其他用户的身份。破坏系统识别客户机/用户的能力会损害API的整体安全性。
如何预防：
确保知道所有可能的API验证流（实现一键式验证的移动/网络/深层链接等）。询问工程师错过了哪些流。
阅读有关身份验证机制的信息。确保了解它们的使用内容和方式。OAuth不是身份验证，API密钥也不是。
不要在身份验证、令牌生成或密码存储方面重新发明轮子，使用标准。
凭据恢复/忘记密码端点应在暴力、速率限制和锁定保护方面被视为登录端点。
要求对敏感操作进行重新身份验证（例如更改帐户所有者的电子邮件地址/2FA电话号码）。
使用OWASP身份验证备忘单。
尽可能实现多因素身份验证。
实现反暴力机制，以减轻身份验证端点上的凭据填充、字典攻击和暴力攻击。此机制应该比API上的常规速率限制机制更严格。
实现帐户锁定/captcha机制，以防止针对特定用户的暴力攻击。实施弱密码检查。
API密钥不应用于用户身份验证。它们只能用于API客户端身份验证。
API3:2023 - Broken Object Property Level Authorization 对象属性级别授权失效
描述：该类别结合了API3:2019过度数据暴露和API6:2019-批量分配，重点关注根本原因：在对象属性级别缺乏或不适当的授权验证。这会导致未经授权的各方暴露或操纵信息。
如何预防：
当使用API端点公开对象时，始终确保用户有权访问公开对象属性。
避免使用to_json（）和to_string（）等泛型方法。相反，选择特别想要返回的特定对象属性。
如果可能，请避免使用将客户端的输入自动绑定到代码变量、内部对象或对象属性（“批量分配”）的函数。
只允许更改客户端应更新的对象属性。
实现基于模式的响应验证机制作为额外的安全层。作为该机制的一部分，定义并强制所有API方法返回的数据。
根据端点的业务/功能需求，将返回的数据结构保持在最低限度。
API4:2023 - Unrestricted Resource Consumption 不受限的资源消耗
描述：满足API请求需要网络带宽、CPU、内存和存储等资源。其他资源，如电子邮件/短信/电话或生物特征验证，由服务提供商通过API集成提供，并按请求付费。成功的攻击可能导致拒绝服务或增加运营成本。
如何预防：
使用一种可以轻松限制内存、CPU、重新启动次数、文件描述符和进程（如Containers/Serverless代码（例如Lambdas））的解决方案。
在所有传入参数和有效载荷上定义并强制执行数据的最大大小，例如字符串的最大长度、数组中元素的最大数量和上传文件的最大大小（无论其是存储在本地还是存储在云存储中）。
对客户端在定义的时间范围内与API交互的频率进行限制（速率限制）。
利率限制应根据业务需求进行微调。一些API端点可能需要更严格的策略。
限制/限制单个API客户端/用户可以执行单个操作的次数或频率（例如，验证OTP，或在不访问一次性URL的情况下请求密码恢复）。
为查询字符串和请求正文参数添加适当的服务器端验证，特别是控制响应中返回的记录数的参数。
为所有服务提供商/API集成配置支出限制。当无法设置支出限制时，应配置计费警报。
API5:2023 - Broken Function Level Authorization 功能级授权失效
描述：具有不同层次结构、组和角色的复杂访问控制策略，以及管理功能和常规功能之间的不明确分离，往往会导致授权缺陷。通过利用这些问题，攻击者可以访问其他用户的资源和管理功能。
如何预防：
在应用程序中有一个一致且易于分析的授权模块，该模块可以从所有业务功能中调用。通常，这种保护是由应用程序代码外部的一个或多个组件提供的。
默认情况下，强制机制应拒绝所有访问，要求明确授予特定角色访问每个功能的权限。
针对功能级授权缺陷检查API端点，同时记住应用程序和组层次结构的业务逻辑。
确保所有管理控制器都继承自一个管理抽象控制器，该控制器基于用户的组/角色实现授权检查。
确保常规控制器内的管理功能根据用户的组和角色执行授权检查。
API6:2023 - Unrestricted Access to Sensitive Business Flows 不受限访问敏感业务
描述：易受此风险影响的API会暴露业务流，例如购买机票或发布评论，而不会补偿如果以自动化方式过度使用该功能可能会对业务造成的损害。这不一定来自于实现错误。
如何预防：
缓解规划应分两层进行：
业务-识别如果过度使用可能会损害业务的业务流。
工程-选择正确的保护机制来降低业务风险。
有些保护机制更为简单，而另一些则更难实施。以下方法用于减缓自动威胁的速度：
设备指纹识别：拒绝向意外的客户端设备（如无头浏览器）提供服务往往会使威胁行为者使用更复杂的解决方案，从而使他们的攻击成本更高
人体检测：使用captcha或更先进的生物识别解决方案（例如打字模式）
非人模式：分析用户流以检测非人模式（例如，用户在不到一秒钟的时间内访问了“添加到购物车”和“完成购买”功能）
考虑阻止Tor出口节点和知名代理的IP地址
保护并限制对机器直接使用的API（如开发人员和B2B API）的访问。它们往往很容易成为攻击者的目标，因为它们通常没有实现所有所需的保护机制。
API7:2023 - Server Side Request Forgery 服务器端请求伪造
描述：当API在未验证用户提供的URI的情况下获取远程资源时，可能会出现服务器端请求伪造（SSRF）缺陷。这使得攻击者能够强迫应用程序将精心编制的请求发送到意外目的地，即使受到防火墙或VPN的保护。
如何预防：
隔离网络中的资源获取机制：通常这些功能旨在检索远程资源，而不是内部资源。
只要可能，请使用以下允许列表：
远程来源用户应从（例如Google Drive、Gravatar等）下载资源
URL方案和端口
给定功能的可接受介质类型
禁用HTTP重定向。
使用经过良好测试和维护的URL解析器来避免URL解析不一致所引起的问题。
验证并清除所有客户端提供的输入数据。
不要向客户端发送原始响应。
API8:2023 - Security Misconfiguration 安全配置错误
描述：API和支持它们的系统通常包含复杂的配置，旨在使API更加可定制。软件和DevOps工程师可能会错过这些配置，或者在配置方面不遵循安全最佳实践，从而为不同类型的攻击打开大门。
如何预防：
API生命周期应包括：
可重复的强化过程，可快速轻松地部署适当锁定的环境
检查和更新整个API堆栈中的配置的任务。审查应包括：编排文件、API组件和云服务（例如S3存储桶权限）
在所有环境中持续评估配置和设置有效性的自动化过程
API9:2023 - Improper Inventory Management 存量资产管理不当
描述：API往往比传统的web应用程序公开更多的端点，这使得正确和更新的文档非常重要。适当的主机清单和部署的API版本对于缓解诸如不推荐的API版本和公开的调试端点等问题也很重要。
如何预防：
清点所有API主机并记录每个主机的重要方面，重点关注API环境（例如生产、暂存、测试、开发），谁应该可以通过网络访问主机（例如公共、内部、合作伙伴）和API版本。
盘点综合服务并记录重要方面，如它们在系统中的作用、交换的数据（数据流）及其敏感性。
记录API的所有方面，如身份验证、错误、重定向、速率限制、跨源资源共享（CORS）策略和端点，包括其参数、请求和响应。
采用开放标准自动生成文档。将文档构建包含在CI/CD管道中。
仅允许授权使用API的人员使用API文档。
使用外部保护措施，例如针对API的所有公开版本的API安全特定解决方案，而不仅仅是针对当前生产版本。
避免将生产数据用于非生产API部署。如果这是不可避免的，那么这些端点应该得到与生产端点相同的安全处理。
当新版本的API包括安全改进时，请执行风险分析，以告知旧版本所需的缓解措施。例如，是否可以在不破坏API兼容性的情况下反向移植改进，或者是否需要快速删除旧版本并强制所有客户端移到最新版本。
API10:2023 - Unsafe Consumption of APIs API的不安全使用
描述：开发人员往往更信任从第三方API接收的数据，而不是用户输入，因此往往采用较弱的安全标准。为了危害API，攻击者追求集成的第三方服务，而不是试图直接危害目标API。
如何预防：
评估服务提供商时，请评估其API安全态势。
确保所有API交互都通过安全通信通道（TLS）进行。
在使用集成API之前，请始终验证并正确清理从集成API接收的数据。
维护一个已知位置的允许列表集成API可能会被重定向至：不要盲目遵循重定向。
稿源：山石网科安全技术研究院（公众号）
