由于滲透測試非常昂貴并且需要很長時間才能運行，因此我們必須以可擴展且可持續的方式執行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一起工作的方式。如果您想了解更多信息，可以從下面的網絡研討會錄像中觀看演示：