DAST 已死，为何业务逻辑安全测试成为焦点

“DAST 已死”——这句话每年都会出现在社交媒体和网络安全新闻通讯中。但如果到了 2024 年，它终于实现了呢？

DAST，动态应用程序安全测试（尽管我们在过去几周内看到了一个新术语“动态 API 安全测试”），在过去十年中一直是应用程序安全测试的基石，但现在是时候让路了下一代应用程序安全测试：业务逻辑安全测试。

为什么理解业务逻辑安全问题对于安全工程师来说变得越来越重要？在这篇文章中，我决定解释这种日益重要的背后的原因。

作为安全人员，我们可能会停止关注基本问题。我们将研究我们的工具很难找到的更困难的问题。就像业务逻辑问题一样……

SDLC 中的安全性：“左移”趋势

在敏捷环境中，开发人员会在我自己的团队中不断更新他们的应用程序（或后端、服务……无论他们如何称呼它们！），有时甚至每天更新。每年进行一两次渗透测试的传统方法不再具有任何意义，因为每次构建都会引入新的漏洞。几年前，手动渗透测试的过时本质对我来说变得非常明显（这也是我决定构建 Escape 的原因之一）。这就是为什么“左移”趋势开始兴起，市场上的安全解决方案必须适应。

适应SDLC的安全解决方案

DAST 工具的最初好处很明显 - 它是唯一可以检测正在运行的应用程序中的漏洞的解决方案（它可以查看应用程序在其环境中的行为方式）。另一方面，软件组合分析 (SCA) 工具主要侧重于列出依赖项中的已知漏洞，而不是评估应用程序的业务逻辑。这一限制缩小了他们识别应用程序核心功能中潜在风险的范围。

很多时候，人们往往过度关注 SDLC 的左侧，而对 SDLC 的右侧关注不够。您可以在供应商中看到它。因此，DAST 工具通常效率非常低，而且它们往往不会产生任何对组织和安全工程师都没有用的东西。所以，很多时候人们只是倾向于说，让我们把 SAST 放在适当的位置，让我们把所有的安全护栏放在左边，而不用担心右边。 

静态应用程序安全测试 (SAST) 工具虽然有用，但由于无法评估运行状态下的应用程序，通常会产生大量误报和漏报。静态分析与应用程序实际运行时行为之间的这种差异阻碍了 SAST 工具查明真正漏洞的有效性。

交互式应用程序安全测试 (IAST) 工具处于中间立场，可在应用程序运行时深入了解应用程序漏洞，从而比 SAST 工具提高准确性。然而，IAST 实现很复杂，并且会在测试期间引入性能开销，因为该工具会主动监视和分析应用程序的行为。

运行时应用程序自我保护 (RASP) 工具面临着不同的挑战，因为它们缺乏生成流量的能力。因此，他们只能在攻击已经损害了应用程序及其基础设施后才能识别漏洞，这使得他们与 DAST 工具相比在威胁缓解方面缺乏主动性。

Escape 的 DAST 与其他安全工具

因此，DAST 出现的时机非常完美：构建完成后，代码刚刚生成且正在运行。它可以在发布后几秒钟无缝集成到 CI/CD 管道或开发/生产环境中，以免为时已晚。作为黑盒测试，它不需要访问代码和流量。

DAST 名声不好却是罪有应得

免责声明：在这一部分中，我什至不会介绍像 Rapid7、Qualys 或 Nessus 这样的 Generalist DAST，它们不测试应用程序层，而只测试网络层；我将重点关注用于测试 API 的 DAST。

1. DAST暴力请求未通过数据验证层

虽然 DAST 理论上是唯一具有完美时机和最有效的“左移”安全解决方案的解决方案，但它也有自己的一系列问题：

当前的 DAST 解决方案不够充分；他们生成毫无意义的请求。他们采用暴力模糊测试。在最好的情况下，它们采用架构（例如 REST API 的 OpenAPI 规范）作为输入来发送正确类型的数据。

然而，仅仅因为标记为电子邮件的字段被标记为字符串并不意味着发送无意义的字符串（例如r4d0omFu!1=1发送到电子邮件字段）是合乎逻辑的。

因此，DAST 中的请求不会通过数据验证层，因此它们会在没有进行任何测试的情况下被卡住。

这是OWASP ZAP（现在的 ZAP）等非常传统的解决方案的主要问题。如今，最著名的 API DAST 供应商只是包装 OWASP ZAP：StackHawk、Checkmarkx、Gitlab、Traceable 等 OWASP ZAP 和第三方服务。

实际上，正如我们的 Escape 与 ZAP 比较（即将在另一篇文章中推出）所证明的那样，大约 0% 的应用程序解析器被 OWASP ZAP 及其来自业务逻辑 POV 的包装器覆盖，这使得它们与 Rapid7、Qualys 一样无效，和 Nessus 用于测试 API。

2. DAST很笨，不会自动执行业务逻辑安全测试

正如微软的 Marina Polishuk 所强调的那样（她的论文“REST-ler：自动智能 REST API 模糊测试”是第一篇认真详细说明此问题的论文），DAST 无法生成和执行与业务逻辑一致的合法请求序列 API。

例如，DAST 无法充分测试特定端点，GET /user/{id}因为它不理解该端点应该{id}源自它之前创建或遇到的用户。因此，在这种情况下无法测试复杂的攻击场景。再次强调，OWASP ZAP 在这方面完全失败了。

有些工具（例如 Nuclei 或 bChecks）可以协助 API 业务逻辑，但不是自动的！事实上，这些解决方案更适合使用简单的指纹技术或手动复杂的业务逻辑（使用硬编码检查）自动评估应用程序的表面。最近的解决方案（例如 Akto）只是 Nuclei 等开源工具的包装。

特别是，Nuclei 和 bChecks 需要手动维护您的测试。这种方法与安全环境不太相符：由于应用程序每天更新，检查是否也应该每天更新和维护？谁负责在组织内实施和维护安全测试？正确评估应用程序及其业务逻辑的安全性需要评估数百种不同安全漏洞的数千种场景。

这将需要每天在每次更新时为每个 API 编写和维护无限数量的手动检查，适应 API 的新用例，每天了解新的 API 安全漏洞以支持新漏洞，实施和调整支票等，这是不现实的。

3.如果DAST声称评估业务逻辑，它需要您组织的数据

一些解决方案声称能够评估 API 的业务逻辑。然而，要做到这一点，他们需要在您的生产环境中有一个代理*，使用您组织的私有数据捕获所有流量和重播请求。

注意：让我们就该上下文中代理的定义达成一致。在 Escape，我们将代理视为安装在客户环境中的任何软件，旨在观察该环境的一部分或与该环境的一部分进行交互。因此，声称“无需代理即可部署[但]只是获取[组织] API流量的副本并将元数据发送到[其服务器]”的解决方案需要代理。

申明“通过与现有安全基础设施集成并实时阻止攻击来修复 API 漏洞，所有这些都无需部署代理或需要网络修改”的解决方案 1) 确实需要代理，2) 不执行业务逻辑测试，而是执行运行时保护。

然后，他们需要访问生产中的客户数据，出于隐私原因，这是侵入性的、过于复杂和危险的。

如果您考虑一下：每次部署测试应用程序的目标是特别关注应用程序的新功能。在这种情况下，使用流量没有任何意义，因为这些新功能尚未暴露给任何流量。 

4. 没有 DAST 真正支持 GraphQL 和其他现代 API

GraphQL 确实非常具体。市场上所有声称支持 GraphQL 的 DAST 解决方案实际上都像 OWASP ZAP 对待 REST API 一样对待 GraphQL。

这意味着没有解决方案尝试发送根据底层 API 的业务逻辑有意义的请求序列。特别是在 GraphQL 中，这些解决方案发送的请求没有考虑图特定的功能，如深度查询、递归查询、别名、批处理、片段等，() 也没有考虑其图性质隐含的众多访问控制问题。 

其他 API 类型如 gRPC、Websockets 等也有其特殊性，目前市场上还没有构建 DAST 解决方案来深入测试这些 API 类型的业务逻辑。

业务逻辑安全测试的本质转变

总之，我们所知道的用于 API 安全测试的 DAST 工具的时代即将结束。正如本文所强调的，DAST 在有效解决现代应用程序漏洞（特别是那些根植于业务逻辑的漏洞）方面的局限性已经变得越来越明显。

虽然 DAST 工具过去已经达到了其目的，但它们无法自动生成与 API 业务逻辑一致的有意义的流量，这凸显了对更先进方法的需求。

Escape 专有的业务逻辑安全测试算法植根于反馈驱动语义 API 探索 (FDSAE) 原则，为下一代安全测试方法铺平了道路。

通过自动生成针对每个 API 的具体细微差别而定制的合法流量，Escape 的解决方案使安全专业人员能够有效应对现代应用程序的挑战和复杂性。

随着公司继续在其开发流程中优先考虑安全性，业务逻辑安全测试无疑将成为确保 API 安全的中心舞台。