Parasoft是構(gòu)建高質(zhì)量軟件的最佳解決方案。從開發(fā)到質(zhì)量檢查,Parasoft的技術(shù)通過集成靜態(tài)和運(yùn)行時分析,單元、功能和API測試,以及服務(wù)虛擬化,在不犧牲質(zhì)量和安全性的情況下加快軟件交付,節(jié)約交付成本。
>>如果您想使用Parasoft測試是否滿足項(xiàng)目要求,可聯(lián)系客服
討論 API 安全性以及為什么我們應(yīng)該關(guān)心它有點(diǎn)像談?wù)摮晕覀兊氖卟恕N覀兌贾莱允卟藢ξ覀兊慕】涤幸妫覀冇卸嗌偃苏嬲龅搅四兀繎?yīng)用程序安全性有點(diǎn)像這樣。雖然它對我們的應(yīng)用程序和我們的業(yè)務(wù)的健康至關(guān)重要,但為它而努力并不像構(gòu)建酷炫的新應(yīng)用程序功能那么有趣。但我們只需要看看最近的新聞標(biāo)題就可以了解它的重要性。
傳統(tǒng)上,驗(yàn)證應(yīng)用程序或 API 的安全性是在開發(fā)過程結(jié)束時完成的。不過,這本質(zhì)上是有問題的。修復(fù)發(fā)現(xiàn)的錯誤通常為時已晚:可能離發(fā)布日期太近而無法修復(fù)問題,或者團(tuán)隊(duì)可能已經(jīng)轉(zhuǎn)移到其他項(xiàng)目,或者應(yīng)用程序的架構(gòu)可能天生不安全。
此外,今天的服務(wù)和應(yīng)用程序比以往任何時候都更頻繁地發(fā)布,通常一天發(fā)布多次。這種快速發(fā)布的節(jié)奏使得傳統(tǒng)方法站不住腳。
由于滲透測試成本高昂且需要很長時間才能運(yùn)行,因此必須以可擴(kuò)展和可持續(xù)的方式執(zhí)行API 安全測試。
進(jìn)入持續(xù)集成
為了解決這個問題,Parasoft將轉(zhuǎn)向業(yè)界一直使用的解決方案,以解決發(fā)布周期加快的軟件質(zhì)量問題——持續(xù)集成。每當(dāng)簽入新代碼時,持續(xù)集成就會生成構(gòu)建,并通過為每個構(gòu)建運(yùn)行靜態(tài)分析和單元測試來驗(yàn)證新代碼。如果團(tuán)隊(duì)很復(fù)雜,他們甚至可能會使用 CI 創(chuàng)建和運(yùn)行自動化功能測試(可能不是針對每個構(gòu)建,因?yàn)楣δ軠y試通常需要很長時間才能運(yùn)行,但至少在指定的時間間隔內(nèi)運(yùn)行,例如每天一次)。
通過將滲透測試引入Parasoft的 CI 工作流程,將相同的解決方案應(yīng)用于 API 的自動化安全測試。這將確保更快地測試安全漏洞,并且它將提供安全回歸測試,可以在新問題出現(xiàn)時立即捕獲它們。但是需要對此保持謹(jǐn)慎,因?yàn)闈B透測試成本高昂,并且可能需要很長時間才能運(yùn)行。必須以可擴(kuò)展和可持續(xù)的方式來做到這一點(diǎn)。
從功能測試開始
假設(shè)團(tuán)隊(duì)已經(jīng)在為 API 編寫和運(yùn)行自動化功能測試,那么作為正常開發(fā)和 QA 流程的一部分,可以確定這些功能測試的子集用作安全測試。將準(zhǔn)備并運(yùn)行這個子集作為安全測試。
首先,讓我們假設(shè)我們有一個 SOAtest 場景,其中包含 1 個清理數(shù)據(jù)庫的設(shè)置測試和 3 個進(jìn)行 3 個不同 API 調(diào)用的測試。我們希望對場景中正在調(diào)用的 3 個 API 中的每一個執(zhí)行滲透測試:
我們將首先通過向場景中的每個測試添加滲透測試工具來準(zhǔn)備安全場景:
然后我們將使用 SOAtest 執(zhí)行這個場景。隨著每個測試的執(zhí)行,SOAtest 將進(jìn)行測試中定義的 API 調(diào)用并捕獲請求和響應(yīng)流量。每次測試中的滲透測試工具都會將流量數(shù)據(jù)傳遞給 OWASP ZAP 滲透測試工具的嵌入式實(shí)例,該工具將根據(jù)它在流量數(shù)據(jù)中觀察到的 API 參數(shù),使用自己的啟發(fā)式方法對 API 執(zhí)行滲透測試。
然后,滲透測試工具將報(bào)告發(fā)現(xiàn)的與訪問 API 的測試相關(guān)的任何錯誤。這是一個示例 SOAtest 報(bào)告,其中包含按 CWE 和嚴(yán)重性組織的所有錯誤:
SOAtest 結(jié)果可以進(jìn)一步報(bào)告到 DTP,Parasoft 的報(bào)告和分析儀表板,以獲得額外的報(bào)告功能。這是其工作原理的表示:
重新利用功能測試作為安全測試有以下好處:
-
由于我們已經(jīng)在編寫功能測試,我們可以重用已經(jīng)完成的工作,節(jié)省時間和精力。
-
要執(zhí)行某些 API,我們可能需要進(jìn)行一些設(shè)置,例如準(zhǔn)備數(shù)據(jù)庫或調(diào)用其他 API。如果我們從已經(jīng)工作的功能測試開始,這個設(shè)置已經(jīng)完成。
-
通常,滲透測試工具會報(bào)告某個 API 調(diào)用存在漏洞,但它不會提供有關(guān)用例和/或它所連接的要求的任何上下文。由于我們使用 SOAtest 來執(zhí)行測試用例,因此在用例的上下文中報(bào)告了安全漏洞。當(dāng)場景與需求相關(guān)聯(lián)時,我們現(xiàn)在可以獲得關(guān)于安全錯誤對應(yīng)用程序的影響的附加業(yè)務(wù)上下文。
-
我們有一個測試場景,可以用來輕松重現(xiàn)錯誤或驗(yàn)證它是否已修復(fù)。
準(zhǔn)備用作安全測試的功能測試
在將功能測試重新用作滲透測試時,需要考慮以下幾點(diǎn):
-
我們應(yīng)該將我們的功能測試場景與我們的安全測試場景分開維護(hù),并從單獨(dú)的測試作業(yè)中運(yùn)行它們。這樣做的主要原因是在現(xiàn)有功能測試中添加滲透測試可能會破壞功能測試的穩(wěn)定性。我們需要選擇哪些功能測試場景應(yīng)該變成自動化安全測試,然后制作功能測試的副本,作為單獨(dú)的安全測試進(jìn)行維護(hù)。
-
我們需要有選擇性地選擇我們選擇的測試,因?yàn)闈B透測試很昂貴;我們需要最大化覆蓋的 API 的攻擊面,同時最小化測試數(shù)量。我們應(yīng)該考慮以下幾點(diǎn):
-
滲透測試工具分析請求/響應(yīng)流量以了解請求中的哪些參數(shù)可供測試。我們需要選擇在每個 API 中執(zhí)行所有參數(shù)的功能測試,以確保 API 的每個輸入都得到分析。
-
在每個場景中,我們需要決定應(yīng)該對哪些 API 調(diào)用進(jìn)行滲透測試。同一個 API 可能會被多個場景引用,我們不希望在不同場景中測試的 API 上重復(fù)滲透測試。滲透測試工具應(yīng)僅添加到要進(jìn)行滲透測試的 API 的適當(dāng)測試中。
-
場景數(shù)量需要可控,以便安全測試運(yùn)行時間足夠短,每天至少運(yùn)行一次。
-
我們的功能測試場景可能有用于初始化或清理的設(shè)置或拆卸部分。這些通常不需要進(jìn)行滲透測試。
-
如果功能測試有任何參數(shù)化,我們應(yīng)該刪除它。滲透測試工具不需要相同參數(shù)的多組值來知道要測試什么,發(fā)送不同的值組可能會導(dǎo)致由于重復(fù)測試而導(dǎo)致測試運(yùn)行時間更長。
-
API 功能測試通常會有驗(yàn)證來自服務(wù)的響應(yīng)的斷言。當(dāng)用作安全測試時,這些斷言可能會失敗,但在審查結(jié)果時會產(chǎn)生噪音,因?yàn)樵谶@種情況下,我們只關(guān)心發(fā)現(xiàn)的安全漏洞。我們應(yīng)該刪除所有斷言。在我之前的示例中,這意味著從測試 3 中刪除 JSON 斷言器。
-
一些 API 調(diào)用將數(shù)據(jù)添加到數(shù)據(jù)庫。當(dāng)針對此類 API 使用滲透測試工具時,由于滲透測試工具針對 API 的攻擊次數(shù)過多,數(shù)據(jù)庫可能會因信息而變得臃腫。在某些情況下,這可能會導(dǎo)致意想不到的副作用。在我們的一個開發(fā)團(tuán)隊(duì)中,當(dāng)特定 API 由于滲透測試攻擊而添加大量數(shù)據(jù)時,我們發(fā)現(xiàn)了應(yīng)用程序中的性能問題。應(yīng)用程序性能變得如此糟糕,以至于無法在合理的時間內(nèi)完成自動安全測試運(yùn)行。我們不得不從我們的自動運(yùn)行中排除該 API 的安全測試,直到我們解決了問題。
維護(hù)穩(wěn)定的測試環(huán)境
我們需要考慮是在相同的測試環(huán)境還是不同的測試環(huán)境中運(yùn)行我們的功能和安全測試。在功能和安全測試運(yùn)行之間重置環(huán)境,或使用單獨(dú)的環(huán)境,可以提高測試穩(wěn)定性,但通常沒有必要。我們經(jīng)常可以重用相同的環(huán)境,但是當(dāng)我們這樣做時,我們應(yīng)該先運(yùn)行功能測試,最后運(yùn)行安全測試,因?yàn)榘踩珳y試會破壞功能測試的環(huán)境。當(dāng)我們使用不同的環(huán)境時,我們需要確保我們使用變量配置原始功能測試場景,以便很容易將測試指向不同環(huán)境的不同端點(diǎn)。SOAtest 使用環(huán)境變量支持這一點(diǎn)。
我們的 API 也可能依賴于我們無法控制的其他 API。我們可以考慮使用服務(wù)虛擬化來隔離我們的環(huán)境,這樣我們就不會依賴那些外部系統(tǒng)。這將有助于穩(wěn)定我們的測試,同時防止由于我們的滲透測試工作對外部系統(tǒng)造成意外后果。
結(jié)論
我們可以通過將安全測試作為自動化流程的一部分轉(zhuǎn)移到開發(fā)和 QA 中來確保我們 API 的質(zhì)量更高。利用現(xiàn)有的 API 功能測試來創(chuàng)建自動化安全測試,這將使我們能夠在流程的早期發(fā)現(xiàn)和修復(fù)安全錯誤。
標(biāo)簽:
本站文章除注明轉(zhuǎn)載外,均為本站原創(chuàng)或翻譯。歡迎任何形式的轉(zhuǎn)載,但請務(wù)必注明出處、不得修改原文相關(guān)鏈接,如果存在內(nèi)容上的異議請郵件反饋至chenjj@fc6vip.cn