OWASP API 安全 Top 10 有了新变化,这对我们意味着什么?
开放全球应用程序安全项目 (OWASP) 最近发布了自 2019 年以来其 API 安全 Top 10 文档的第一个更新版本的候选版本(草案)。让我们回顾一下在该草案中提议的更改,看看哪些关键因素正在影响当今的 API 漏洞,以便您可以更好地了解保护 API 的旅程。
什么是 OWASP Top 10?
OWASP 是一个非政府组织,它根据社区反馈和专家评估创建安全意识文档,描述当今组织中最常见的漏洞类型。
OWASP Top 10 于 2003 年首次发布,并定期更新。 TOP 10 名的受众范围从开发人员到安全分析师再到 CISO。 有些人专注于文档的更多技术方面,有些人使用它来确保他们购买的产品具有正确的覆盖范围。
OWASP API Top 10
除了 Web 应用程序安全 Top 10 之外,OWASP 还发布了一份单独的 API Top 10 文档,以强调 API 安全需要一种独特的方法。?OWASP API 安全项目?“专注于理解和减轻应用程序编程接口 (API) 的独特漏洞和安全风险的策略和解决方案。”
API Top 10 自 2019 年以来没有更新过。从那时起,各行业对 API 的依赖变得更加普遍,70% 的开发人员今年预计将增加?API 的使用。
OWASP API 安全 Top 10 候选发布版本的最新更新现已推出。 让我们回顾一下今天的 API 漏洞格局有何不同(图 1)。
图 1:2019 年以来 OWASP API Top 10 的变化
近期的变化中有哪些亮点
API3:2023 BOPLA 与 API1:2023 BOLA 有什么不同
批量分配和过度数据泄露现在合并到损坏对象属性级别授权 (BOPLA) 中。失效的对象级授权 (BOLA) 和 BOPLA 之间的区别在于,BOLA 引用整个对象,而 BOPLA 引用对象内部的属性(图 2)。
图 2:BOPLA 指的是对象内部的属性
在新的定义中要求防御者更深入地研究对象,这增加了检测攻击所需的复杂性和业务逻辑理解水平。
被 BOLA 涵盖并不意味着您也被 BOPLA 所涵盖,将批量分配和过度数据暴露合并到一个类别中强调了对象中属性所需的注意。
对于选择 API 安全产品的 CISO 来说,这种区别非常重要,因为他们需要确保产品涵盖这两种攻击。
API6:2023 服务器端请求伪造已加入,API8:2019 注入已退出
OWASP 社区放弃了注入的严重性并添加了服务器端请求伪造 (SSRF)。 这是一个大胆的举措,它表明托管安全服务提供商的格局正在发生变化,以及人们对安全产品开箱即用地解决威胁的期望正在发生变化。 此更改还允许在 TOP 10 中提供另一个攻击媒介的详细信息。
以下是 OWASP 社区选择进行此更改的一些建议原因:
- 在云中,Kubernetes 和 Docker 通过 API 传递 URL,因此更多的 API 可能比注入更容易受到 SSRF 的攻击。
- 使用流行的服务(SaaS、PaaS、CloudaaS 等)比命令(例如 SSO 和 OAuth 2.0)更有可能公开 URL,并且更有可能进行重定向。
- 注入现在本质上属于 API7:2023 安全配置错误的一部分
- 适当的安全配置包括 Web 应用程序防火墙,默认情况下应防止注入。
API8:2023 缺乏对自动威胁的保护是 TOP?10 中的新内容
OWASP 建议,随着时间的推移,限速防御措施的有效性会降低,除了实施缺陷或任何其他漏洞外,机器人程序可以通过按预期使用 API 以自动化方式对公司造成伤害。 详情参考?OWASP 对 Web 应用程序的自动化威胁,它没有提供针对 API 的独特视角,但采用了通用方法。
以下是您需要了解的有关此补充的信息:
- 自动化威胁正在攻克防御并变得更加复杂。
- API 是焦点,因为它的目标是大规模服务。
- 自动化威胁防御层必须观察所有业务逻辑,而不仅仅是 API。
API10:2023 API 的不安全使用也是 TOP?10 中的新增内容
由于 - aaS 类产品的迅速发展,API 往往需要与不同的内部和外部(第三方)服务进行集成和通信,发送数据和接收数据。 在这些情况下遵循 “基本” 安全规则也很重要,安全产品在这个领域检测 / 主动防御可能会很复杂。
OWASP 在其文档中包含了一系列建议,包括一般建议和特定于 API 的建议,例如:
- 仔细遵循重定向。
- 将该种监督纳入业务逻辑
- 拥有检查 / 监控 / 检查流量的安全产品
- 不要相信第三方的 API,尽管它们通常为付费服务(例如,推荐引擎或搜索引擎)。
- 在您的应用程序中建立防御和限制
最终见解与要点
新的 OWASP API 安全 Top 10 发布候选版本是朝着 API 特定方向迈出的重要一步,它与以应用程序为中心的 Top 10 有所不同,并强调了 API 威胁的独特性。
需要记住的一些要点包括:
- API 难以保护。 攻击非常复杂,可能是特定于客户的,并且可能需要了解 API 内部的业务逻辑。 因此,安全产品可能需要更高的计算能力才能充分保护 API。
- OWASP 强调了 API 安全领域的几个新主题:
- 不应信任第三方和内部服务
- 云环境、容器和 Kubernetes 作为 API 安全性的一部分(在高级别)包含在内,并在 URL 传递的高风险 (SSRF) 中发挥作用
- “授权” 在前五大 API 攻击主题中占了四名。其强调了 API 授权的复杂性,以及测试和识别由错误的 API 逻辑而不是软件问题引起的漏洞的难度。
有关 API 的其他信息
Akamai 跟踪 API 的使用情况和 API 流量,作为其互联网状况 (SOTI) 报告的一部分。 您可以阅读以前的 SOTI 报告以了解更多信息,并查看每个季度的新 SOTI 报告。
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。 如若内容造成侵权/违法违规/事实不符,请联系我的编程经验分享网邮箱:veading@qq.com进行投诉反馈,一经查实,立即删除!