?

討論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功能測試來創建自動化的安全測試，這將使我們能夠在流程中更早地發現和修復安全錯誤。希望這能幫助我們不成為下一個軟件故障的新聞大頭條之一......

總結

以上是生活随笔為你收集整理的如何使API安全测试成为CI流程的自动化部分？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。