注意!请主动识别 API 漏洞,从生产到代码

Wake up! Identify API Vulnerabilities Proactively, From Code Back to Production

在 2021 年的一项调查中,73% 的企业表示他们已经发布了 50 多个 API,并且这个数字还在不断增长。

API 在当今几乎每个行业中都发挥着至关重要的作用,并且随着它们走向业务战略的前沿,它们的重要性正在稳步增加。这不足为奇:API 无缝连接不同的应用程序和设备,带来前所未有的业务协同效应和效率。

但是,API 就像软件的任何其他组件一样存在漏洞。除此之外,如果它们没有从安全角度进行严格测试,它们还会引入一系列全新的攻击面,并使您面临前所未有的风险。如果您等到生产环境才发现 API 漏洞,则可能会导致大量延迟。

API 对攻击者具有吸引力,而不仅仅是企业

请记住,API 不仅仅是连接您的应用程序;它们以不可预测的方式改变了功能。API 可能引入的许多独特弱点为黑客所熟知,他们开发了不同的方法来攻击您的 API 以访问底层数据和功能。

根据OWASP API Top 10,合法的、经过身份验证的用户通过利用看似合法但实际上旨在操纵 API 的调用来利用 API 的情况并不少见。这种旨在操纵业务逻辑和利用设计缺陷的攻击对攻击者很有吸引力。

您会看到,每个 API 都是独一无二且专有的。因此,它的软件错误和漏洞也是独一无二的,也是“未知的”。导致业务逻辑或业务流程级别攻击的错误类型特别难以识别为防御者。

Wake up! Identify API Vulnerabilities Proactively, From Code Back to Production

您是否给予 API 安全测试足够的重视?

许多组织已经广泛接受左移安全性,允许在整个开发过程中进行持续测试。然而,API 安全测试经常失败或在没有充分了解所涉及的风险的情况下进行。这是为什么?嗯,原因不止一个:

  1. 现有应用安全测试工具通用性强,针对传统Web应用漏洞,无法有效处理API复杂的业务逻辑。
  2. 由于 API 没有 UI,因此公司通常会分别测试 Web、应用程序和移动设备,而不是 API 本身。
  3. 测试 API 可能需要大量手动操作,并且在您拥有数百个 API 时不可扩展。
  4. 相关经验和专业知识可能短缺,因为 API 测试比其他类型的测试更复杂
  5. 对于遗留 API,您可能不了解已实现的 API 或文档。

因此,虽然通常许多组织已经重视左移安全性,但 API 安全性测试往往被排除在 DevSecOps 大局之外。

这很不幸,因为 API 漏洞需要比传统应用程序漏洞更长的时间来修复 – 在最近的一项调查中,63% 的受访者表示修复 API 漏洞需要更长的时间。鉴于应用程序对 API 的迅速采用和依赖,这个数字也可能会上升。

Wake up! Identify API Vulnerabilities Proactively, From Code Back to Production

虽然大多数安全领导者都意识到 API 安全测试的重要性,但只有不到一半的人表示他们还没有将 API 安全测试解决方案完全集成到他们的开发管道中。

为什么常见的安全测试方法无法覆盖 API?

作为迈向综合方法的第一步,重要的是检查当今对应用程序安全测试最常见的态度:静态安全测试和动态安全测试。

静态安全测试采用白盒方法,通过审查设计、架构或代码,包括数据在通过应用程序时可能采用的许多复杂路径,基于应用程序的已知功能创建测试。

动态安全测试采用黑盒方法,在给定一组特定输入的情况下,根据应用程序的预期性能创建测试,而忽略内部处理或底层代码知识。

当谈到 API 时,开发人员和安全团队经常争论这两种方法中的哪一种最合适,支持每种方法的主要推理是:

  • 静态测试是唯一有意义的方法:因为 API 没有用户界面,所以您必须知道业务逻辑内部发生了什么。
  • 只需要动态测试,因为单元测试使用静态模型并且已经在管道的早期阶段完成。

很抱歉毁了聚会,但这两点都只是部分正确。事实上,这两种方法对于确保广泛的覆盖范围和处理各种可能的场景都是必要的。特别是随着当前基于 API 的攻击的兴起,在可扩展性、深度和频率方面,您不能冒险。

Wake up! Identify API Vulnerabilities Proactively, From Code Back to Production

“灰盒”API 安全测试可能会提供一个有趣的替代方案。由于没有用户界面,了解应用程序的内部工作原理(例如,参数、返回类型)可以帮助您有效地创建专注于业务逻辑的功能测试。

理想情况下,结合 API 安全测试的各个方面将使您更接近创建一个灰盒解决方案,以弥补这些单独方法中的每一个的弱点。这种业务逻辑方法可以智能地检查其他测试类型的结果,并可以自动或手动应用改进的测试。

是时候采用业务逻辑 API 安全测试方法了

越来越多的行业意识到需要在 API 的整个生命周期内保护它们,将 API 放在安全控制的前沿和中心位置。

为此,您必须找到方法来简化和简化组织的 API 安全测试,在开发周期内集成和执行 API 安全测试标准。这样,连同运行时监控,安全团队可以在一个地方了解所有已知漏洞。作为奖励,采取措施进行左移 API 安全测试将降低成本并加快修复时间。

此外,一旦您的测试工作流程自动化,您还将获得对重新测试的内置支持:测试、修复、重新测试和部署的循环,使您的管道平稳运行并完全避免瓶颈。

API 安全测试的业务逻辑方法可以提升您的全生命周期 API 安全计划的成熟度,并改善您的安全状况。

Wake up! Identify API Vulnerabilities Proactively, From Code Back to Production

但是,这种现代方法需要一种可以随时间学习的工具,通过摄取运行时数据来深入了解应用程序的结构和逻辑,从而随着时间的推移提高其性能。

这将涉及创建一个自适应测试引擎,该引擎可以边运行边学习,深入了解 API 的行为,以便智能地对其隐藏的内部工作原理进行逆向工程。使用运行时数据和业务逻辑信息,您可以享受两全其美 – 黑白盒方法通过自动化增强可见性和控制。

最后

除了越来越受欢迎之外,API 还为 Web 应用程序创造了更大的漏洞。许多组织甚至不知道他们的 API 和漏洞的程度。黑客可以通过可用的 API 轻松探测已知和未知的弱点。

然而,API 安全测试经常被忽视,并且与 Web 应用程序一样处理。大多数测试方法,例如黑盒和白盒测试,都不利于 API 测试。

自然语言处理和人工智能 (AI) 的结合提供了一个可行的“灰盒”选项,可以自动化、扩展和简化 API 安全测试的复杂过程。

 

注意!请主动识别 API 漏洞,从生产到代码

极牛网精选文章《注意!请主动识别 API 漏洞,从生产到代码》文中所述为作者独立观点,不代表极牛网立场。如若转载请注明出处:https://geeknb.com/15436.html

(38)
打赏 微信公众号 微信公众号 微信小程序 微信小程序
上一篇 2021年7月22日 下午12:09
下一篇 2021年7月23日 上午10:24

相关推荐

发表评论

登录后才能评论