前言

TesterHome有人專門加了我QQ問安全測試這個話題，所以這篇準備先聊聊持續交付中的安全測試。
現在資訊保安已經上升到了國家戰略的高度，特別是今年《中華人民共和國網路安全法》頒佈後，使用者隱私通過國家立法的方式被嚴格要求保護，另外一方面安全灰產行業風起雲湧，形成了一個巨大的地下產業鏈條和破壞能力。在此背景下，越來越多的網際網路公司也開始組建自己的安全職能部門，但也會發現很多公司的軟體並沒有經過專門的安全測試便執行在網際網路上，它們攜帶著各類安全漏洞直接暴露在公眾面前，其中一些漏洞甚至直指軟體所承載的核心敏感資訊或業務邏輯。這裡既有企業安全意識的問題，也有安全人才缺乏的原因，目前軟體測試團隊大多數人的視野仍還停留在功能驗收，或效能自動化等傳統領域，對於安全測試，則往往會感覺水太深了不知從何下手。

網際網路公司的安全團隊

在軟體測試的這些領域裡，安全測試確實是一個比較特別的科目。在幾年前，企業招聘安全人員一般都是放在運維部門，主要工作還是掃描和伺服器加固等，搭建IDS/IPS/WAF等安全裝置進行對抗，這些安全裝置說起來很唬人，市場也賣的很好，但是如果脫離業務光依靠安全裝置堆疊，真正擋住了多少黑客攻擊？估計抓的最多的還是漫無目的的蠕蟲。
本人幾年前有幸從無到有進行了安全團隊的組建，從自己做滲透測試到現在逐漸組建了10人左右的專業安全團隊，慢慢也接觸和熟悉了這個方向，覆蓋領域從應用安全逐漸擴充套件到運維安全、安全風控、安全合規等各個方面，並自主進行了WAF和IDS等系統的研發。
這個方向確實有不少其獨特的地方，但放下其他幾個不表，至少在應用安全這個方向，“神祕的安全測試人員”（一般我們也喜歡招聘有滲透經驗的白帽子們）不光是名字跟軟體測試人員一樣都有“測試”二字，所做的事情在本質上也是跟軟體測試人員有很多相通。

持續交付中的安全測試

回到持續交付這個話題，在過往的軟體研發過程中，安全測試（類似的也包括效能、APP專項等測試）由於其專業性，一般是作為軟體開發的較末環節開始手工執行和驗收。但持續交付/devops的大潮提高了速度並擴張了規模，讓安全和效能等專項團隊也面臨著新的挑戰。為確保快速開發和新功能部署，安全團隊必須確保安全評估的頻率，既要保證安全風險最小化，同時也要考慮安全團隊有限資源的可持續性，權衡DevOps速度與現有安全要求的需求也在安全行業內催生了一個名為DevSecOps的模型（類似的還有DevTestOps的概念,不詳細展述）。
即使在持續整合（CI）和持續交付（CD）過程中還不能實現完整的自動化軟體安全評估（人工的滲透測試依然不可缺少），但這個方向仍然有不少可以自動化實施的實踐。其中自動化的靜態程式碼掃描，依賴元件掃描以及初級的滲透測試都可以比較容易的在交付流水線中實現，參見下面截圖（為了pipeline的執行效率，相互不依賴幾個整合測試環節可以併發執行）

程式碼安全檢查

利用靜態程式碼掃描工具對程式碼在編譯之前進行掃描，並在靜態程式碼層面上發現各種問題，其中包括安全問題。部分工具列表：

為了方便與sonarQube整合，我們使用的是FindbugSecurity,根據企業實際情況定製了規則，在持續構建的過程中，會進行程式碼靜態安全檢查。

通過檢查可以很快發現程式碼中sql注入，XSS、密碼硬編碼儲存、不安全配置等問題。

pipeline中只需要整合sonarqube的程式碼檢查即可，通過sonar的質量閾判斷pipeline是否通過。

stage('靜態檢查') {
           when { 
               expression
                   {return isCA} 
           }
           steps {
               echo "starting codeAnalyze with SonarQube......"
               //sonar:sonar.QualityGate should pass
               withSonarQubeEnv('SonarQube') {
                 //固定使用專案根目錄${basedir}下的pom.xml進行程式碼檢查  
                 sh "mvn -f pom.xml clean compile sonar:sonar"
               }
               script {
               timeout(10) { 
                   def qg = waitForQualityGate() 
                       if (qg.status != 'OK') {
                           error "未通過Sonarqube的程式碼質量閾檢查，請及時修改！failure: ${qg.status}"
                       }
                   }
               }
           }
       }

依賴元件安全檢查

由於當前伺服器應用依賴的第三方的庫和框架越來越多、越來越複雜，比如SSL、Spring、Rails、Hibernate、.Net，以及各種第三方認證系統等。而且系統開發的時候一般選定某個版本後在很長一段時間內都不會更新，因為更新的成本一般都比較高。但是往往這些依賴為了新增新的功能和修復各種當前的問題——當然包括安全問題，卻會經常更新。開源專案的安全問題只要被發現以後，通常都會被公佈到網上去，比如CVE、CWE等，導致很多人都可能利用它去攻擊使用這些依賴的系統。比如說這兩年出盡風頭的萬年漏洞王 Struts2每次在0DAY漏洞爆發後，都造成了大量的網站淪陷，對整個網際網路行業都造成了嚴重恐慌。
依賴元件檢查就是通過掃描當前系統使用到的所有第三方依賴，並和網上公佈的安全漏洞庫進行比較，如果當前某個第三方依賴存在某種危險級別（需要自己定義）的漏洞，就立即發出警告（比如通過pipeline阻止釋出等）來通知開發人員或者系統管理員，從而在最短的時間內修復這個問題，防止攻擊，避免或者減少損失。
部分工具列表：

我們使用Dependency-Check來做元件檢查，先在Jenkins中安裝OWASP Dependency-Check Plugin外掛，並在pipiline中增加對應stage

stage('依賴安全檢查') {
    when { 
        expression
            {return isDC} 
    }
     steps{
          //指定檢測**/lib/*.jar的元件
         dependencyCheckAnalyzer datadir: '', hintsFile: '', includeCsvReports: false, includeHtmlReports: false, includeJsonReports: false, isAutoupdateDisabled: false, outdir: '', scanpath: '**/lib/*.jar', skipOnScmChange: false, skipOnUpstreamChange: false, suppressionFile: '', zipExtensions: ''
        //有高級別元件漏洞時，fail掉pipeline
        dependencyCheckPublisher canComputeNew: false, defaultEncoding: '', failedTotalHigh: '0', healthy: '', pattern: '', unHealthy: ''

     }
 }

元件檢查結果如下

重點關注存在高危漏洞的元件

安全漏洞詳情

安全滲透掃描

此類方法一般適用在web安全測試領域，針對Web應用的安全掃描工具非常多，其中OWASP ZAP是免費軟體裡面最為常用的。部分工具列表：

web安全掃描一般分為兩種型別：主動掃描和被動掃描。
主動掃描
主動掃描是首先給定需要掃描的系統地址，掃描工具通過某種方式訪問這個地址，如使用各種已知漏洞模型進行訪問，並根據系統返回的結果判定系統存在哪些漏洞；或者在訪問請求中嵌入各種隨機資料（模糊測試）進行一些簡單的滲透性測試和弱口令測試等。主動掃描覆蓋測試面會比較大，但缺點是完成一次全面掃描非常耗時(一般都需要幾個小時)，所以我們沒有選用這種方式在pipeline中進行整合，更合適的方式可能還是搞個job在半夜的時候做定時掃描然後第二天來檢視掃描報告。
被動掃描
被動掃描的基本原理就是設定掃描工具為一個Proxy Server，功能測試通過這個代理服務訪問系統，掃描工具可以截獲所有的互動資料並進行分析，通過與已知安全問題進行模式匹配，從而發現系統中可能的安全缺陷。在實踐中，為了更容易地整合到CI，如果有比較完善的Web自動化測試用例，一般會在執行自動化功能測試的時候使用被動掃描方法，從而實現持續安全掃描。

被動掃描的具體實現也非常簡單，在下載安裝好ZAP後，後續的過程都可以在pipeline上進行組織。
1.配置WebDriver,為其設定代理到ZAP的地址
2.啟動ZAP並執行web自動化測試：zapStart build -Dzap.proxy=localhost:7070，執行web自動化測試指令碼
3.生成安全測試報告：zapReport
4.關閉ZAP：zapStop
備註：如果要執行主動掃描可以使用命令“zapStart zapScan”，在執行過程中使用“zapScanStatus”檢視狀態，當掃描完成後，生成安全掃描報告並關閉ZAP“zapReport zapStop”。

安全測試報告：

相對於程式碼安全檢查和依賴元件檢查，安全滲透掃描適用的場景較少，在web自動化用例不是太豐富的情況效果比較有限，不過還是可以作為一個安全滲透的冒煙測試，在專業滲透測試工程師資源有限的情況下提供一個安全基線的檢查。

結語

安全測試是個非常複雜的過程，依靠自動化掃描器並不能發現所有的安全問題，但是它可以在較小投入的情況下持續發現大部分系統的基礎安全問題。如果需要更高級別的安全保障，人工滲透性測試和威脅建模等必不可少，但成本也是相對較高的。
安全測試絕不應該是測試工程師的禁區，不管是在測試思想還是工程實踐上，安全測試都脫離不了持續交付和敏捷的軟體工程體系。相信未來安全測試，也肯定會和軟體開發測試的過程結合的越來越緊密，而不再是現在這樣只限於白帽子這個小眾的圈子。
所以這裡致所有測試同仁們，讓我們也開始做安全測試吧。

https://testerhome.com/topics/10323