彩票走势图

由于渗透测试非常昂贵并且需要很长时间才能运行，因此我们必须以可扩展且可持续的方式执行API安全测试。

讨论API安全性以及我们为什么要注意的问题有点像谈论吃蔬菜。我们都知道吃蔬菜对我们的健康有益，但实际上我们当中有多少人呢？应用程序安全性就是这样。这对于我们的应用程序和业务的健康至关重要，但努力做到这一点并不像构建出色的新应用程序功能那么有趣。但是，我们只需要查看最近的新闻头条即可了解它的重要性。

传统上，在开发过程的最后要完成针对安全性的应用程序或API的验证。但是，这本质上是有问题的。通常，为时已晚，无法解决发现的错误：可能太接近发布日期，无法解决问题，或者团队可能已经转移到其他项目，或者应用程序的体系结构固有地不安全。

此外，当今的服务和应用程序的发布比以往任何时候都更加频繁，一天最多可以发布多次。这种快速释放的节奏使传统方法难以为继。

输入持续集成

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

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

从功能测试开始

我假设我们的团队已经在为我们的API编写和运行自动化功能测试。（如果我们不这样做，则需要从这里开始，并且不准备考虑进行安全性测试的自动化。）如果我们正在为API运行自动化功能测试，那么作为我们正常开发和质量检查流程的一部分，我们可以确定这些功能测试的一部分，用作安全性测试。我们将准备并运行此子集作为安全性测试。

让我描述一下如何使用Parasoft SOAtest及其与流行的渗透测试工具Burp Suite的集成。首先，假设我们有一个SOAtest场景，其中有1个设置测试可以清理数据库，而3个测试则可以进行3个不同的API调用。我们要针对场景中要调用的3个API分别执行渗透测试：

首先，我们将Burp Suite Analysis工具添加到方案中的每个测试中，以准备方案的安全性，如下所示：

然后，我们将使用SOAtest执行此方案。在执行每个测试时，SOAtest将进行测试中定义的API调用，并捕获请求和响应流量。每次测试中的Burp Suite分析工具都会将流量数据传递到Burp Suite应用程序的单独运行实例，该实例将根据自己在流量数据中观察到的API参数，使用自己的启发式方法对API进行渗透测试。然后，Burp Suite分析工具将获取Burp Suite发现的所有错误，并将其报告为SOAtest中与访问API的测试相关的错误。然后可以将SOAtest结果进一步报告到Parasoft的报告和分析仪表板DTP中，以获取其他报告功能。请参见以下内容，了解其工作原理：

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

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

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

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

1. 我们应该将功能测试方案与安全测试方案分开维护，并在单独的测试作业中运行它们。这样做的主要原因是，将渗透测试添加到现有功能测试中可能会破坏功能测试的稳定性。我们需要选择将哪些功能测试方案转换为自动化安全测试，然后制作将作为独立安全测试维护的功能测试副本。
2. 由于渗透测试非常昂贵，因此我们必须选择选择哪种测试。我们需要最大程度地覆盖所涵盖的API的攻击面，同时最大程度地减少测试次数。我们应该考虑以下几点：
1. 渗透测试工具分析请求/响应流量，以了解请求中的哪些参数可供测试。我们需要选择功能测试，以测试每个API中的所有参数，以确保对API的每个输入进行分析。
2. 在每种情况下，我们都需要确定应进行渗透测试的API调用。可能会在多个场景中引用相同的API，并且我们不想在另一个场景中对正在测试的API进行渗透测试。Burp Suite分析工具应仅添加到要进行渗透测试的API的适当测试中。
3. 方案的数量需要可管理，以便安全测试运行足够短以每天至少运行一次。
3. 我们的功能测试方案可能包含用于初始化或清除的设置或拆卸部分。这些通常不需要进行渗透测试。
4. 如果功能测试具有任何参数化，则应将其删除。渗透测试工具不需要为同一参数使用多组值即可知道要测试的内容，而发送不同组的值可能会由于重复测试而导致测试运行时间更长。
5. API功能测试通常会包含验证服务响应的断言。当用作安全性测试时，这些断言可能会失败，但在查看结果时会产生干扰，因为在这种情况下，我们仅关注发现的安全性漏洞。我们应该删除所有断言。在我之前的示例中，这意味着从测试3中删除JSON声明器。
6. 一些API调用会将数据添加到数据库。当针对此类API使用渗透测试工具时，由于渗透测试工具针对API的攻击次数众多，数据库中的信息可能会冗余。在某些情况下，这可能会导致意外的副作用。在我们的一个开发团队中，当特定的API由于渗透测试攻击而添加大量数据时，我们发现了应用程序中的性能问题。应用程序性能变得如此糟糕，以至于阻止了自动安全测试在合理的时间内完成。在解决问题之前，我们不得不从自动运行中排除该API的安全性测试。

维持稳定的测试环境

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

我们的API也可能依赖我们无法控制的其他API。我们可以考虑使用服务虚拟化来隔离我们的环境，因此我们不依赖那些外部系统。这将有助于稳定我们的测试，同时避免由于我们的渗透测试工作而给外部系统带来意想不到的后果。

结论

作为自动化流程的一部分，我们可以将安全性测试转移到开发和质量保证中，从而确保API的质量更高。我们可以利用现有的API功能测试来创建自动化的安全测试，这将使我们能够在流程的早期发现并修复安全错误。希望这将有助于我们不要成为新闻的下一个负面头条......

Parasoft主持了一个网络研讨会，其中包括演示如何与Parasoft SOAtest和Burp Suite一起工作的方式。如果您想了解更多信息，可以从下面的网络研讨会录像中观看演示：