Parasoft自动化测试案例：如何使 API 安全测试成为 CI 过程的自动化部分

翻译|使用教程|编辑：张莹心|2021-11-04 16:18:17.667|阅读 201 次

概述：通过将安全测试作为自动化流程的一部分转移到开发和 QA 中来确保 API 的质量更高。利用现有的 API 功能测试来创建自动化安全测试，将能够在流程的早期发现和修复安全错误。

Parasoft是构建高质量软件的最佳解决方案。从开发到质量检查，Parasoft的技术通过集成静态和运行时分析，单元、功能和API测试，以及服务虚拟化，在不牺牲质量和安全性的情况下加快软件交付，节约交付成本。

>>如果您想使用Parasoft测试是否满足项目要求，可联系客服

讨论 API 安全性以及为什么我们应该关心它有点像谈论吃我们的蔬菜。我们都知道吃蔬菜对我们的健康有益，但我们有多少人真正做到了呢？应用程序安全性有点像这样。虽然它对我们的应用程序和我们的业务的健康至关重要，但为它而努力并不像构建酷炫的新应用程序功能那么有趣。但我们只需要看看最近的新闻标题就可以了解它的重要性。

传统上，验证应用程序或 API 的安全性是在开发过程结束时完成的。不过，这本质上是有问题的。修复发现的错误通常为时已晚：可能离发布日期太近而无法修复问题，或者团队可能已经转移到其他项目，或者应用程序的架构可能天生不安全。

此外，今天的服务和应用程序比以往任何时候都更频繁地发布，通常一天发布多次。这种快速发布的节奏使得传统方法站不住脚。

由于渗透测试成本高昂且需要很长时间才能运行，因此必须以可扩展和可持续的方式执行API 安全测试。

进入持续集成

为了解决这个问题，Parasoft将转向业界一直使用的解决方案，以解决发布周期加快的软件质量问题——持续集成。每当签入新代码时，持续集成就会生成构建，并通过为每个构建运行静态分析和单元测试来验证新代码。如果团队很复杂，他们甚至可能会使用 CI 创建和运行自动化功能测试（可能不是针对每个构建，因为功能测试通常需要很长时间才能运行，但至少在指定的时间间隔内运行，例如每天一次）。

通过将渗透测试引入Parasoft的 CI 工作流程，将相同的解决方案应用于 API 的自动化安全测试。这将确保更快地测试安全漏洞，并且它将提供安全回归测试，可以在新问题出现时立即捕获它们。但是需要对此保持谨慎，因为渗透测试成本高昂，并且可能需要很长时间才能运行。必须以可扩展和可持续的方式来做到这一点。

从功能测试开始

假设团队已经在为 API 编写和运行自动化功能测试，那么作为正常开发和 QA 流程的一部分，可以确定这些功能测试的子集用作安全测试。将准备并运行这个子集作为安全测试。

首先，让我们假设我们有一个 SOAtest 场景，其中包含 1 个清理数据库的设置测试和 3 个进行 3 个不同 API 调用的测试。我们希望对场景中正在调用的 3 个 API 中的每一个执行渗透测试：

如何使 API 安全测试成为 CI 过程的自动化部分

我们将首先通过向场景中的每个测试添加渗透测试工具来准备安全场景：

如何使 API 安全测试成为 CI 过程的自动化部分

然后我们将使用 SOAtest 执行这个场景。随着每个测试的执行，SOAtest 将进行测试中定义的 API 调用并捕获请求和响应流量。每次测试中的渗透测试工具都会将流量数据传递给 OWASP ZAP 渗透测试工具的嵌入式实例，该工具将根据它在流量数据中观察到的 API 参数，使用自己的启发式方法对 API 执行渗透测试。

然后，渗透测试工具将报告发现的与访问 API 的测试相关的任何错误。这是一个示例 SOAtest 报告，其中包含按 CWE 和严重性组织的所有错误：

如何使 API 安全测试成为 CI 过程的自动化部分

SOAtest 结果可以进一步报告到 DTP，Parasoft 的报告和分析仪表板，以获得额外的报告功能。这是其工作原理的表示：

如何使 API 安全测试成为 CI 过程的自动化部分

重新利用功能测试作为安全测试有以下好处：

由于我们已经在编写功能测试，我们可以重用已经完成的工作，节省时间和精力。
要执行某些 API，我们可能需要进行一些设置，例如准备数据库或调用其他 API。如果我们从已经工作的功能测试开始，这个设置已经完成。
通常，渗透测试工具会报告某个 API 调用存在漏洞，但它不会提供有关用例和/或它所连接的要求的任何上下文。由于我们使用 SOAtest 来执行测试用例，因此在用例的上下文中报告了安全漏洞。当场景与需求相关联时，我们现在可以获得关于安全错误对应用程序的影响的附加业务上下文。
我们有一个测试场景，可以用来轻松重现错误或验证它是否已修复。

准备用作安全测试的功能测试

在将功能测试重新用作渗透测试时，需要考虑以下几点：

我们应该将我们的功能测试场景与我们的安全测试场景分开维护，并从单独的测试作业中运行它们。这样做的主要原因是在现有功能测试中添加渗透测试可能会破坏功能测试的稳定性。我们需要选择哪些功能测试场景应该变成自动化安全测试，然后制作功能测试的副本，作为单独的安全测试进行维护。
我们需要有选择性地选择我们选择的测试，因为渗透测试很昂贵；我们需要最大化覆盖的 API 的攻击面，同时最小化测试数量。我们应该考虑以下几点：

渗透测试工具分析请求/响应流量以了解请求中的哪些参数可供测试。我们需要选择在每个 API 中执行所有参数的功能测试，以确保 API 的每个输入都得到分析。
在每个场景中，我们需要决定应该对哪些 API 调用进行渗透测试。同一个 API 可能会被多个场景引用，我们不希望在不同场景中测试的 API 上重复渗透测试。渗透测试工具应仅添加到要进行渗透测试的 API 的适当测试中。
场景数量需要可控，以便安全测试运行时间足够短，每天至少运行一次。

我们的功能测试场景可能有用于初始化或清理的设置或拆卸部分。这些通常不需要进行渗透测试。
如果功能测试有任何参数化，我们应该删除它。渗透测试工具不需要相同参数的多组值来知道要测试什么，发送不同的值组可能会导致由于重复测试而导致测试运行时间更长。
API 功能测试通常会有验证来自服务的响应的断言。当用作安全测试时，这些断言可能会失败，但在审查结果时会产生噪音，因为在这种情况下，我们只关心发现的安全漏洞。我们应该删除所有断言。在我之前的示例中，这意味着从测试 3 中删除 JSON 断言器。
一些 API 调用将数据添加到数据库。当针对此类 API 使用渗透测试工具时，由于渗透测试工具针对 API 的攻击次数过多，数据库可能会因信息而变得臃肿。在某些情况下，这可能会导致意想不到的副作用。在我们的一个开发团队中，当特定 API 由于渗透测试攻击而添加大量数据时，我们发现了应用程序中的性能问题。应用程序性能变得如此糟糕，以至于无法在合理的时间内完成自动安全测试运行。我们不得不从我们的自动运行中排除该 API 的安全测试，直到我们解决了问题。

维护稳定的测试环境

我们需要考虑是在相同的测试环境还是不同的测试环境中运行我们的功能和安全测试。在功能和安全测试运行之间重置环境，或使用单独的环境，可以提高测试稳定性，但通常没有必要。我们经常可以重用相同的环境，但是当我们这样做时，我们应该先运行功能测试，最后运行安全测试，因为安全测试会破坏功能测试的环境。当我们使用不同的环境时，我们需要确保我们使用变量配置原始功能测试场景，以便很容易将测试指向不同环境的不同端点。SOAtest 使用环境变量支持这一点。

我们的 API 也可能依赖于我们无法控制的其他 API。我们可以考虑使用服务虚拟化来隔离我们的环境，这样我们就不会依赖那些外部系统。这将有助于稳定我们的测试，同时防止由于我们的渗透测试工作对外部系统造成意外后果。