如何使API安全测试成为CI流程的自动化部分？
讨论API安全以及为什么我们应该关心，有点像讨论吃蔬菜。我们都知道吃蔬菜对我们的健康有好处，但是我们有多少人真正做到了呢？应用安全就有点像这样。它对于我们的应用和业务的健康是必不可少的，但努力实现它并不像构建很酷的新应用功能那样有趣。然而，我们只要看看最近的新闻头条就能明白它有多重要。
传统上，验证应用程序或API的安全性是在开发过程的最后完成的。不过，这本身就存在问题。在这个过程中，发现的错误通常为时已晚，无法修复：可能离发布日期太近，无法修复问题，或者团队可能已经转移到其他项目上，或者应用程序的架构可能本身就不安全。
此外，如今的服务和应用的发布频率比以往任何时候都要高，往往一天要发布多次。这种快速的发布节奏使得传统的方法无法维持。
进入持续集成
为了解决这个问题，我们将求助于业界一直在使用的一种解决方案，以加速发布周期来解决软件质量问题——持续集成。持续集成每当新代码被检查到时就会产生构建，并通过为每个构建运行静态分析和单元测试来验证新代码。如果团队很成熟，他们甚至可能会使用CI创建和运行自动化的功能测试（也许不是为每个构建，因为功能测试通常需要很长的时间来运行，但至少在指定的时间间隔，如每天一次）。
我们可以通过将渗透测试引入CI工作流，将同样的解决方案应用于API的自动化安全测试。这将确保我们更早地测试安全漏洞，它将为我们提供安全回归测试，可以在新问题出现时立即发现它们。但是，我们需要聪明地对待它，因为渗透测试是昂贵的，并且可能需要很长的时间来运行。我们必须以可扩展和可持续的方式进行测试。
从功能测试开始
我假设我们的团队已经在为我们的API编写和运行自动化功能测试。如果我们没有这样做，我们需要从这里开始，并且还没有准备好考虑自动化我们的安全测试）。如果我们正在为我们的 API 运行自动化功能测试，那么作为我们正常开发和 QA 流程的一部分，我们可以从这些功能测试中确定一个子集作为安全测试。我们将准备并运行这个子集作为安全测试。
让我用Parasoft SOAtest及其与Burp Suite（一种流行的渗透测试工具）的集成来描述它是如何工作的。首先，让我们假设我们有一个SOAtest场景，其中有1个清理数据库的设置测试，以及3个进行3个不同API调用的测试。我们要对场景中被调用的3个API分别进行渗透测试：
我们首先要为场景的安全性做准备，为场景中的每个测试添加一个Burp Suite分析工具，如下图所示：
然后我们将使用SOAtest执行这个场景。当每个测试执行时，SOAtest会进行测试中定义的API调用，并捕获请求和响应流量。每个测试中的Burp Suite分析工具将把流量数据传递给单独运行的Burp Suite应用程序实例，该实例将根据它在流量数据中观察到的API参数，使用自己的启发式方法对API进行渗透测试。然后，Burp Suite分析工具将把Burp Suite发现的任何错误作为错误在SOAtest中报告，并与访问API的测试相关联。SOAtest 的结果可以进一步报告到 DTP（Parasoft 的报告和分析仪表板）中，以获得额外的报告功能。请看下面的工作原理：
将功能测试重新用于安全测试有以下好处：
- 由于我们已经在编写功能测试，我们可以重用已经完成的工作，节省时间和精力。
- 为了执行某些API，我们可能需要做一些设置，比如准备数据库或调用其他API。如果我们从已经工作的功能测试开始，这个设置就已经完成了。
- 通常情况下，渗透测试工具会报告某个API调用存在漏洞，但它并没有给出任何关于它所连接的用例和/或需求的上下文。由于我们是使用SOAtest来执行测试用例，所以安全漏洞是在用例的上下文中报告的。当场景已经与需求相关联时，我们现在可以获得关于安全错误对应用程序影响的额外业务上下文。
- 我们有一个测试场景，我们可以用它来轻松地重现错误或验证它是否已经被修复。
准备功能测试作为安全测试使用
在将功能测试重新用于渗透测试时，有几件事需要考虑：
- 我们应将功能测试方案与安全测试方案分开，并从不同的测试任务中运行。这样做的主要原因是，在现有的功能测试中加入渗透测试，很可能会起到破坏功能测试稳定性的作用。我们需要选择哪些功能测试场景应该变成自动化的安全测试，然后将功能测试的副本制作成单独的安全测试来维护。
- 我们需要有选择地选择哪些测试，因为渗透测试的成本很高；我们需要在尽量减少测试数量的同时，最大化覆盖API的攻击面。我们应该考虑以下几点：
- 渗透测试工具会分析请求/响应流量，以了解请求中哪些参数是可以测试的。我们需要选择行使每个API中所有参数的功能测试，以确保API的每个输入都得到分析。
- 在每个场景中，我们需要决定哪些API调用应该进行渗透测试。同一 API 可能会从多个场景中被引用，我们不希望对正在不同场景中测试的 API 进行重复渗透测试。Burp Suite 分析工具应该只被添加到要进行渗透测试的 API 的适当测试中。
- 场景的数量需要可控，以便安全测试运行时间足够短，每天至少运行一次。
- 我们的功能测试场景可能有设置或拆除部分，用于初始化或清理。这些通常不需要进行渗透测试。
- 如果功能测试有任何参数化，我们应该将其删除。渗透测试工具不需要为相同的参数提供多组值来知道要测试什么，而发送不同的值集可能只会导致由于重复测试而使测试运行时间更长。
- API功能测试通常会有验证服务响应的断言。当作为安全测试时，这些断言可能会失败，但在审查结果时将会产生噪音，因为在这种情况下，我们只关心被发现的安全漏洞。我们应该删除所有的断言。在我之前的例子中，这意味着从测试3中删除JSON断言器。
- 一些API调用会向数据库添加数据。当使用渗透测试工具对这类API进行攻击时，由于渗透测试工具对API进行攻击的次数，数据库可能会因信息而变得臃肿。在某些情况下，这会造成意想不到的副作用。在我们的一个开发团队中，当某个API由于渗透测试攻击而增加了大量数据时，我们发现了应用程序的性能问题。应用程序的性能变得非常糟糕，以至于无法在合理的时间内完成自动化安全测试运行。我们不得不将该 API 的安全测试从自动化运行中排除，直到我们解决了这个问题。
维护稳定的测试环境
我们需要考虑是在同一个测试环境中运行功能测试和安全测试，还是在不同的环境中运行。在功能测试和安全测试运行之间重新设置环境，或者使用一个单独的环境，可以促进更好的测试稳定性，但通常没有必要。我们经常可以重用同一个环境，但当我们这样做时，我们应该先运行功能测试，最后运行安全测试，因为安全测试会破坏功能测试的环境稳定性。当我们使用不同的环境时，我们需要确保我们用变量配置原始的功能测试场景，这样就可以很容易地将测试指向不同环境的不同端点。SOAtest使用环境变量支持这一点。
我们的API也可能依赖于我们控制之外的其他API。我们可以考虑使用服务虚拟化来隔离我们的环境，这样我们就不会依赖这些外部系统。这将有助于稳定我们的测试，同时防止由于我们的渗透测试工作对外部系统造成意外的后果。
总结一下
我们可以通过将安全测试作为自动化流程的一部分，将安全测试转移到开发和QA中，从而确保我们的API质量更好。我们可以利用现有的API功能测试来创建自动化的安全测试，这将使我们能够在流程中更早地发现和修复安全错误。希望这能帮助我们不成为下一个软件故障的新闻大头条之一......
