2019測試指南-測試&測試原理

什麼是測試？
在Web應用程序的開發生命週期中，須要測試許多東西，但測試實際上意味着什麼？Merriam-Webster Dictionary將測試描述爲：

• 進行測試或證實。

• 進行測試。

• 根據測試分配站立或評估。

出於本文檔的目的，測試是將系統或應用程序的狀態與一組標準進行比較的過程。在安全行業中，人們常常根據既不明確也不完整的一套心理標準進行測試。所以，許多外人將安全測試視爲黑色藝術。本文檔的目的是改變這種見解，並使沒有深刻安全知識的人更容易在測試中發揮做用。

爲什麼進行測試？
本文檔旨在幫助組織瞭解測試程序的內容，並幫助他們肯定在Web應用程序上構建和運行測試程序所需採起的步驟。該指南提供了製做全面的Web應用程序安全程序所需元素的普遍視圖。本指南可用做參考指南和方法，以幫助肯定現有實踐與行業最佳實踐之間的差距。本指南容許組織將本身與業界同行進行比較，瞭解測試和維護軟件所需的資源量，或準備審計。本章不涉及如何測試應用程序的技術細節，由於其目的是提供典型的安全組織框架。

何時測試？
今天的大多數人都不會測試軟件，直到它已經被建立並處於其生命週期的部署階段（即，代碼已經建立並實例化爲工做的Web應用程序）。這一般是一種很是無效且成本太高的作法。防止安全漏洞出如今生產應用程序中的最佳方法之一是經過在每一個階段中包含安全性來改進軟件開發生命週期（SDLC）。SDLC是強加於軟件文物開發的結構。若是當前沒有在您的環境中使用SDLC，則應該選擇一個！下圖顯示了通用SDLC模型以及在此類模型中修復安全漏洞的（估計）增長的成本。

公司應檢查其總體SDLC，以確保安全性是開發過程當中不可或缺的一部分。SDLC應包括安全測試，以確保充分覆蓋安全性，而且控制在整個開發過程當中都是有效的。

測試什麼？
將軟件開發視爲人員，流程和技術的組合可能會有所幫助。若是這些是「建立」軟件的因素，那麼這些是必須測試的因素是合乎邏輯的。今天，大多數人一般會測試技術或軟件自己。

有效的測試程序應該包含測試的組件：

• 人 - 確保有足夠的教育和意識;

• 流程 - 確保有足夠的政策和標準，人們知道如何遵循這些政策; 
  * 技術 - 確保流程在實施過程當中有效。

除非採用總體方法，不然僅測試應用程序的技術實現不會發現可能存在的管理或操做漏洞。經過測試人員，策略和流程，組織能夠捕獲稍後會表現爲技術缺陷的問題，從而及早消除錯誤並肯定缺陷的根本緣由。一樣，僅測試系統中可能存在的一些技術問題將致使不完整且不許確的安全狀態評估。

測試原理

---

在開發測試方法以發現軟件中的安全漏洞時，存在一些常見的誤解。本章介紹了專業人員在對軟件執行安全測試時應考慮的一些基本原則。

沒有銀色子彈
雖然很容易認爲安全掃描器或應用程序防火牆會提供許多防護攻擊或識別大量問題，但實際上對於不安全的軟件問題沒有靈丹妙藥。應用程序安全評估軟件雖然可用做尋找低調成果的第一步，但在深刻評估或提供足夠的測試覆蓋率方面一般是不成熟和無效的。請記住，安全是一個過程，而不是一個產品。

從戰略上思考，而不是戰術
在過去的幾年中，安全專業人員已經意識到在1990年代廣泛存在於信息安全中的補丁和滲透模型的謬誤。補丁和滲透模型涉及修復報告的錯誤，但沒有正確調查根本緣由。此模型一般與下圖所示的漏洞窗口相關聯。全球使用的通用軟件中漏洞的演變代表該模型的無效性。有關漏洞窗口的更多信息，請參閱[6]。

漏洞研究[7]代表，隨着全球攻擊者的反應時間，典型的漏洞窗口沒法爲補丁安裝提供足夠的時間，由於漏洞被發現與對其開發和釋放的自動攻擊之間的時間正在減小每一年。

在補丁和穿透模型中有幾個不正確的假設。許多用戶認爲補丁會干擾正常操做，並可能破壞現有應用程序。假設全部用戶都知道新發布的補丁也是錯誤的。所以，產品的全部用戶都不會應用修補程序，由於他們認爲修補可能會干擾軟件的工做方式，或者由於他們缺少有關修補程序存在的知識。

必須在軟件開發生命週期（SDLC）中構建安全性，以防止應用程序中出現重複出現的安全問題。開發人員能夠經過制定適合並在開發方法中工做的標準，策略和指南，爲SDLC構建安全性。應使用威脅建模和其餘技術來幫助爲最危險的系統部分分配適當的資源。 

SDLC是王者
SDLC是一個爲開發人員所熟知的過程。經過將安全性集成到SDLC的每一個階段，它容許採用總體的應用程序安全性方法，利用組織內部已有的過程。請注意，雖然各個階段的名稱可能會根據組織使用的SDLC模型而發生變化，但原型SDLC的每一個概念階段都將用於開發應用程序（即定義，設計，開發，部署，維護）。每一個階段都有安全考慮因素，應該成爲現有流程的一部分，以確保具備成本效益和全面的安全計劃。

存在幾種安全的SDLC框架，它們提供描述性和規範性建議。一我的是否採起描述性或規定性建議取決於SDLC流程的成熟度。從本質上講，說明性建議顯示了安全SDLC應該如何工做，描述性建議顯示了它在現實世界中的使用方式。二者都有本身的位置。例如，若是您不知道從哪裏開始，則說明性框架能夠提供能夠在SDLC中應用的潛在安全控制菜單。而後，描述性建議能夠經過展現對其餘組織有效的方法來幫助推進決策過程。描述性安全SDLC包括BSIMM-V; 規範性安全SDLC包含OWASP的開放軟件保障成熟度模型（OpenSAMM）和ISO / IEC 27034第1-8部分，  
早期測試和常常測試
當在SDLC早期檢測到錯誤時，能夠更快地以更低的成本解決問題。在這方面，安全性錯誤與功能性或基於性能的錯誤沒有什麼不一樣。實現這一目標的關鍵步驟是教育開發和QA團隊瞭解常見的安全問題以及檢測和預防這些問題的方法。雖然新的庫，工具或語言能夠幫助設計更好的程序（安全漏洞更少），但新的威脅不斷出現，開發人員必須意識到影響他們正在開發的軟件的威脅。安全測試教育還能夠幫助開發人員從攻擊者的角度得到適當的思惟模式來測試應用程序。這容許每一個組織將安全問題視爲其現有職責的一部分。 
瞭解安全範圍瞭解
給定項目須要多少安全性很是重要。應該給予要保護的信息和資產一個分類，說明如何處理它們（例如，機密，祕密，絕密）。應與法律委員會進行討論，以確保知足任何特定的安全要求。在美國，要求可能來自聯邦法規，如Gramm-Leach-Bliley法案[8]，或州法律，如加州SB-1386 [9]。對於位於歐盟國家/地區的組織，可能適用特定國家/地區的法規和歐盟指令。例如，指令96/46 / EC4 [10]規定，不管申請是什麼，都必須謹慎處理申請中的我的數據。 
培養正確的心態
成功測試應用程序的安全漏洞須要「開箱即用」。正經常使用例將在用戶以預期方式使用應用程序時測試應用程序的正常行爲。良好的安全測試須要超出預期，而且像攻擊者試圖破解應用程序同樣思考。創造性思惟能夠幫助肯定哪些意外數據可能致使應用程序以不安全的方式失敗。它還能夠幫助發現Web開發人員所作的假設並不是老是如此，以及如何將其顛覆。 
理解主題
任何良好的安全計劃中的第一個主要計劃之一應該是要求準確記錄應用程序。架構，數據流圖，用例等應該用正式文檔編寫並提供給咱們審查。技術規範和應用程序文檔應包括不只列出所需用例，並且還列出任何特定不容許的用例的信息。最後，至少有一個基本的安全基礎設施是很好的，它容許監視和趨勢對組織的應用程序和網絡（例如，IDS系統）的攻擊。 
使用正確的工具
雖然咱們已經說過沒有銀彈工具，但工具確實在整個安全計劃中起着關鍵做用。有一系列開源和商業工具能夠自動執行許多平常安全任務。這些工具能夠經過協助安全人員完成任務來簡化和加快安全過程。可是，重要的是要準確理解這些工具可以作什麼和不能作什麼，以便它們不會被超賣或錯誤地使用。 
細節決定成敗
相當重要的是，不要對應用程序進行表面的安全性審查，並認爲它是完整的。這將灌輸一種虛假的信心感，這種信心可能與沒有首先進行安全審查同樣危險。仔細審查調查結果並清除報告中可能存在的任何誤報相當重要。報告不正確的安全性查找一般會破壞安全報告其他部分的有效消息。應該注意驗證應用程序邏輯的每一個可能部分都已通過測試，而且針對可能的漏洞探索了每一個用例場景。 
使用源代碼時可用
雖然黑盒滲透測試結果能夠使人印象深入而且有助於演示生產環境中漏洞的暴露程度，但它們並非保護應用程序最有效或最有效的方法。動態測試很難測試整個代碼庫，特別是在存在許多嵌套條件語句的狀況下。若是應用程序的源代碼可用，則應在安全人員執行審查時向他們提供幫助。能夠發現應用程序源中的漏洞，這些漏洞在黑匣子參與期間會被遺漏。  
制定指標
良好的安全計劃的一個重要部分是可以肯定事情是否變得更好。跟蹤測試約定的結果很是重要，並開發可以揭示組織內應用程序安全趨勢的指標。

好的指標將顯示： 

• 若是須要更多的教育和培訓;

• 若是開發團隊沒有明確理解特定的安全機制;

• 若是每月發現的安全相關問題總數正在降低。

能夠從可用源代碼以自動方式生成的一致度量標準還將幫助組織評估爲減小軟件開發中的安全性錯誤而引入的機制的有效性。度量標準不易開發，所以使用OWASP Metrics項目和其餘組織提供的標準度量標準是一個很好的起點。
記錄測試結果
爲了完成測試過程，重要的是要生成正式記錄，記錄測試操做採起的操做，執行人員，執行時間以及測試結果的詳細信息。明智的作法是就報告的可接受格式達成一致，這對全部相關方都有用，可能包括開發人員，項目管理，業務全部者，IT部門，審計和合規性。

業務全部者應清楚地肯定報告存在重大風險的位置，並足以得到後續緩解措施的支持。開發人員還應清楚地向開發人員說明受漏洞影響的確切功能以及用開發人員理解的語言解決問題的相關建議。該報告還應容許另外一個安全測試人員重現結果。編寫報告不該該對安全測試程序自己形成太重負擔。安全測試人員一般不會因其創造性寫做技能而聞名，而且就複雜報告達成一致可能會致使測試結果沒法正確記錄的狀況。使用安全測試報告模板能夠節省時間並確保準確一致地記錄結果，