Parasoft自動化測試案例：如何使 API 安全測試成為 CI 過程的自動化部分

翻譯|使用教程|編輯：張瑩心|2021-11-04 16:18:17.667|閱讀 278 次

概述：通過將安全測試作為自動化流程的一部分轉移到開發和 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。我們可以考慮使用服務虛擬化來隔離我們的環境，這樣我們就不會依賴那些外部系統。這將有助于穩定我們的測試，同時防止由于我們的滲透測試工作對外部系統造成意外后果。