最后更新于2023年8月10日星期四21:39:38 GMT
The OWASP十大API安全风险2023 has arrived! OWASP的API Top 10一直是一个备受期待的版本，可以作为今年API安全准备的关键组成部分. 正如我们在 针对不断变化的攻击面的API安全最佳实践， API的使用持续飙升. 因此，API安全覆盖必须比以往任何时候都更加先进.
OWASP十大API安全风险是什么?
OWASP十大API安全风险是2023年基于API的最高优先级威胁列表. 让我们更深入地研究OWASP十大API安全风险列表中的每一项，以概述您可能遇到的威胁类型以及减少每种威胁的适当响应.
1. 损坏的对象级授权
对象级授权是一种控制方法，它限制对对象的访问，以最大限度地减少系统暴露. 处理对象的所有API端点都应该利用用户组策略执行授权检查.
我们建议在接收客户端输入以从数据存储访问对象的每个函数中使用此授权机制. 作为一种额外的硬化手段, 建议使用加密安全的随机GUID值作为对象引用id.
2. 破碎的身份验证
身份验证与处理访问API的用户或实体的身份的所有端点和数据流相关. 这包括凭据、密钥、令牌，甚至密码重置功能. 身份验证失败可能导致许多问题，例如凭据填充, 暴力攻击, 弱无符号密钥, 过期的代币.
身份验证涵盖了广泛的功能，需要严格的审查和强有力的实践. 应该针对所有身份验证功能执行详细的威胁建模，以理解数据流, entities, 以及API所涉及的风险. 应尽可能实施多因素身份验证，以减轻凭据泄露的风险.
防止暴力破解和其他自动密码攻击, 应以合理的阈值实施费率限制. 不应该接受弱的和过期的凭证，这包括jwt、密码和密钥. 还应该对所有令牌执行完整性检查, 确保签名算法和签名值的有效性，防止篡改攻击.
3. 损坏的对象属性级别授权
与对象级授权相关, 对象属性级授权是另一种控制方法，用于限制对对象的特定属性或字段的访问. 此类别结合了2019年OWASP API Security的“过度数据暴露”和“大规模分配”两个方面。. 如果API端点暴露了不应被未经授权的用户读取或修改的敏感对象属性，则认为它是易受攻击的.
总体缓解策略是验证处理对象属性的所有API端点中的用户权限. 根据需要，对属性和字段的访问应该保持在最低限度，并限定在给定端点的功能范围内.
4. 无限制的资源消耗
API资源消耗属于CPU, memory, storage, network, 以及API的服务提供者使用情况. 拒绝服务攻击是由于这些资源的过度消耗导致停机和累积的服务费用.
设置与业务功能需求相关的最小和最大限制是降低资源消耗风险的总体策略. API端点应该以每个客户端为基础限制速率和最大调用数. 对于API基础设施, 使用具有定义的资源限制的容器和无服务器代码将降低服务器资源消耗的风险.
限制资源消耗的编码实践也需要到位. 限制API响应中返回的记录数量，并酌情谨慎使用分页. 文件上传也应该有大小限制，以防止过度使用存储空间. Additionally, 必须仔细评估正则表达式和其他数据处理方法的性能，以避免高CPU和内存消耗.
5. 破碎的功能级别授权
在API端点后面的控制器或函数中缺少授权检查是在破碎的功能级授权下进行的. This vulnerability class allows attackers to access unauthorized functionality; whether they are changing an HTTP method from a `GET` to a `PUT` to modify data that is not expected to be modified, 或者将URL字符串从' user '更改为' admin '. 由于控制器的复杂性以及用户组和角色的数量，正确的授权检查可能很困难.
针对API架构和设计的全面威胁建模对于防止这些漏洞至关重要. 确保API功能是精心构建的，并且相应的控制器正在执行身份验证检查. For example, ' /api/v1/admin '端点下的所有功能都应该由执行严格身份验证检查的admin控制器类来处理. 当有疑问时，应默认拒绝访问，并应根据需要提供赠款.
6. 对敏感业务流的无限制访问
自动化威胁正变得越来越难以应对，必须根据具体情况逐一解决. 如果敏感功能暴露在这样一种方式下，如果发生过度的自动化使用，可能会造成伤害，那么API是脆弱的. 可能没有特定的实现错误, 而是可以以自动化方式滥用的业务流的公开.
威胁建模练习作为整体缓解策略非常重要. 必须仔细考虑业务功能和所有数据流, 并且必须讨论过度自动化使用的威胁场景. 从实现的角度来看, 指纹识别设备, 人工检测, 不规则API流和序列模式检测, IP封锁可以根据具体情况实施.
7. 服务器端请求伪造
当客户端将URL或其他远程资源作为数据提供给API时，就会发生服务器端请求伪造(SSRF)漏洞. 结果是代表API向该URL发出精心制作的出站请求. 这些在重定向URL参数、webhook、文件获取功能和URL预览中很常见.
攻击者可以通过多种方式利用SSRF. 云提供程序和容器的现代使用暴露了实例元数据url和内部管理控制台，可能会泄漏凭据和滥用特权功能. 内部网络调用，如后端服务到服务请求, 即使受到服务网格和mTLS的保护, 能产生意想不到的结果吗. 内部存储库, build tools, 和其他内部资源都可能成为SSRF攻击的目标.
我们建议验证和清理所有客户端提供的数据，以减轻SSRF漏洞. 在实现资源获取功能时，必须强制执行严格的允许列表. 允许列表应该是细粒度的, 限制除指定服务外的所有服务, URLs, schemes, ports, 媒体类型. If possible, 将此功能隔离在受控的网络环境中，并进行仔细监控，以防止探测内部资源.
8. 安全错误配置
API堆栈中任何部分的错误配置都可能导致安全性降低. 这可能是补丁不完整或不一致的结果, 启用不必要的功能, 或者不正确地配置权限. 攻击者将枚举API的整个表面区域来发现这些错误配置, 哪些可能被用来泄露数据, 滥用额外功能, 或者在过时的组件中查找其他漏洞.
有一个健壮的, fast, 可重复的加固过程对于降低错误配置问题的风险至关重要. 安全更新必须通过补丁管理过程定期应用和跟踪. 应该定期审查整个API堆栈的配置. 应该考虑使用资产管理和漏洞管理解决方案来自动化这个强化过程.
9. 库存管理不当
具有多个相互连接的api的复杂服务带来了一个困难的库存管理问题，并带来了更多的风险. 在各种环境中使用多个版本的api进一步增加了挑战. 不适当的库存管理可能导致运行未打补丁的系统并将数据暴露给攻击者. 现代微服务使得部署许多应用程序比以往任何时候都更容易, 拥有强大的库存管理实践是很重要的.
包括主机在内的所有资产的文档, applications, environments, 并且应该在资产管理解决方案中仔细收集和管理用户. 所有第三方集成都需要进行审查和记录, as well, 以了解任何风险暴露. API文档应该是标准化的，并可供授权使用API的人员使用. 仔细控制对环境的访问和更改，以及与外部共享的内容. internally, 数据保护措施必须到位，以确保生产数据不会落入其他环境.
10. 不安全地使用api
必须谨慎处理从其他api使用的数据，以防止意外行为. 第三方API可能被破坏，并被用来攻击其他API服务. SQL注入等攻击, XML外部实体注入, 反序列化的攻击, and more, 在处理来自其他api的数据时应该考虑什么.
仔细的开发实践必须到位，以确保所有数据都得到验证和适当的处理. 评估第三方集成和服务提供商的安全状态. 确保所有API通信都通过安全通道(如TLS)进行. 在建立服务之间的连接时，还应该强制执行相互身份验证.
What's next?
OWASP十大API安全风险模板现在已经准备好，可以在InsightAppSec中使用, 将每个Rapid7的API攻击模块映射到相应的OWASP类别，以便于参考和增强API威胁覆盖范围.
确保使用新模板来确保针对API安全威胁的最佳类覆盖! 当然，通常情况下，确保你遵循Rapid7 best practices 来保护您的api.
