關於安全性測試，咱們須要知道的一些事

關於安全性測試，咱們須要知道的一些事

一、安全性測試的最佳時機：

         不少企業只有在產品成型或者即將部署上線後纔開始作安全性測試，這是一種成本高且低效的作法，最佳實踐應該是在整個產品安全開發生命週期（SDLC）的不一樣階段實施相應的安全措施。企業應當在SDLC中讓安全成爲產品設計和開發的一部分。

2、越早越頻繁就越好：

         安全性缺陷和普通的bug並無區別，越早發現修復成本就越低。要作到這一步，最關鍵的就是對開發以及QA人員進行安全培訓，告訴他們安全缺陷可以形成什麼樣的影響，以及如何檢測和修復這些缺陷。雖然新興的第三方庫、工具以及編程語言可以幫助開發人員寫出更加安全的程序，可是他們最好可以意識到新產生的安全漏洞是否對正在開發的產品有影響。另外，安全培訓也可以讓開發人員站在攻擊者的角度去對產品進行內部測試。

3、明確產品的安全需求：

         瞭解產品的安全需求是很是重要的，對須要保護的信息或資產須要進行密級分類（好比：保密、機密和高度機密等），避免在不重要的業務上花費過多時間。此外，在不一樣的國家的對安全的要求和標準是不同的，最好和法律顧問專家一塊兒討論明確這方面的安全需求。

4、跳出常規思惟定勢：

         只有跳出常規的思惟定勢才能執行一次成功的安全性測試。常規的測試用例只可以覆蓋目標程序的正常行爲，而一次好的滲透測試要求人員站在攻擊者的角度去思考各類沒法預期的狀況去攻破程序。創造性的思惟能夠幫助咱們分析使用什麼樣的數據，在哪一種不安全的方式下能夠致使程序失效，同時也能幫助咱們猜想開發人員的是如何開發的，以及如何繞過程序的防禦邏輯，這也是爲何說使用安全自動化測試工具不是一種有效的安全測試方式，由於創造性思惟必須是case by case的，不一樣的開發人員開發同一個程序都會有不一樣的結果。

5、深刻了解目標：

         進行安全性測試前，最重要的事情是拿到被測試目標的相關文檔，好比：架構設計、數據流圖、用例等等，這些技術規格和應用程序文檔不只須要記錄正常的用例，也要記錄不容許發生的用例。

6、千萬別忽略細節：

         一次好的安全性測試絕對不是一次簡單的程序review，咱們必須儘可能確保程序的每一處邏輯和用例都被覆蓋到，對於認爲是誤報的點也不能放過，必須反覆確認。

7、使用源代碼：

         因爲黑盒測試並不能覆蓋程序內部的全部邏輯，因此它不是最有效的作安全性測試的手段，若是手頭上有目標程序的源代碼，就必定要進行源碼級別的審計，有時候可以發現一些黑盒測試沒法發現的問題。