討論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功能測試通常會有驗證服務響應的斷言。當作為安全測試時，這些斷言可能會失敗，但在審查結果時將會產生噪音，因為在這種情況下，我們只關心被發現的安全漏洞。我們應該刪除所有的斷言。在我之前的例子中，這意味著從測試
3中刪除
json
斷言器。
一些api呼叫會向資料庫新增資料。當使用滲透測試工具對這類
api進行攻擊時，由於滲透測試工具對
api進行攻擊的次數，資料庫可能會因資訊而變得臃腫。在某些情況下，這會造成意想不到的***。在我們的乙個開發團隊中，當某個
api由於滲透測試攻擊而增加了大量資料時，我們發現了應用程式的效能問題。應用程式的效能變得非常糟糕，以至於無法在合理的時間內完成自動化安全測試執行。我們不得不將該
api
的安全測試從自動化執行中排除，直到我們解決了這個問題。
我們需要考慮是在同乙個測試環境中執行功能測試和安全測試，還是在不同的環境中執行。在功能測試和安全測試執行之間重新設定環境，或者使用乙個單獨的環境，可以促進更好的測試穩定性，但通常沒有必要。我們經常可以重用同乙個環境，但當我們這樣做時，我們應該先執行功能測試，最後執行安全測試，因為安全測試會破壞功能測試的環境穩定性。當我們使用不同的環境時，我們需要確保我們用變數配置原始的功能測試場景，這樣就可以很容易地將測試指向不同環境的不同端點。soatest使用環境變數支援這一點。
我們的api也可能依賴於我們控制之外的其他
api。我們可以考慮使用服務虛擬化來隔離我們的環境，這樣我們就不會依賴這些外部系統。這將有助於穩定我們的測試，同時防止由於我們的滲透測試工作對外部系統造成意外的後果。
我們可以通過將安全測試作為自動化流程的一部分，將安全測試轉移到開發和qa中，從而確保我們的
api質量更好。我們可以利用現有的
api功能測試來建立自動化的安全測試，這將使我們能夠在流程中更早地發現和修復安全錯誤。希望這能幫助我們不成為下乙個軟體故障的新聞大頭條之一
......
api介面加密 如何解決API介面開發安全性呢？
如今各種api介面層出不窮，乙個api的好與不好有很多方面可以考量，其中 安全性 是乙個api介面最基本也是最重要的乙個特點。尤其是對於充值繳費類的api介面來說，如話費充值api介面 流量充值api介面 遊戲q幣充值 水電煤繳費介面等，安全與否直接影響到個人或企業的財產，所以做好的api介面安全性...
Postman 測試 API 如何上傳檔案
很多時候我們都會用 postman 來測試 api。在最開始的時候，我們都會使用字串呀什麼的來進行測試，隨著 api 的繼續開發，我們希望通過 api 來上傳檔案。如何在 postman 中進行設定來上傳檔案？postman 已經幫我們想到了。在進入 postman 以後，找到你需要進行測試的 ap...
如何做安全測試？
文章目錄 前言1.web安全測試 1.基本安全測試 2.認證測試 3.會話管理測試 4.許可權管理測試 5.檔案和目錄測試 鏈結前言 不做文字的搬運工，多做靈感性記錄 這是平時學習總結的地方，用做知識庫 平時看到其他文章的相關知識，也會增加到這裡 隨著學習深入，會進行知識拆分和彙總，所以文章會隨時更...