2 種方式在流水線中集成 DAST，動態保護應用程序安全詳情 - devsecops,devops,安全,運維,ci 極狐GitLab 博客

💡 如何在流水線中集成與應用 DAST ？

近日，在「DevSecOps軟件安全開發實踐」課程上，極狐(GitLab) 前端工程師錢堃、極狐(GitLab) 高級後端工程師張林傑，展開了關於 DAST 的概念、必要性、優缺點的內容分享，並結合實操演示，幫助大家進一步掌握 DAST 技術。

以下內容整理自本次直播，你也可以點擊👉觀看視頻回放或下載 PPT。Enjoy～

DevSecOps 在 DevOps 的基礎上增加了 Sec（Security，安全）的概念，是指通過與 Sec （安全團隊）+ Dev（研發團隊） + Ops（運營團隊）合作，在標準 DevOps 週期中建立關鍵的安全原則。

DevSecOps 提倡 “安全左移” 的理念，即在軟件生命週期（SDLC）的早期階段就注重安全問題，從而防止缺陷產生以及儘早找出漏洞。

在軟件開發生命週期不同階段發現漏洞，其修復成本（人力、財力等）不一樣。如下圖所示，如果説需求階段發現一個漏洞，其修復成本是 1，在編碼階段就變成了 5，而在生產階段變成了驚人的 30，這意味着：生產階段漏洞修復成本 = 需求階段漏洞修復成本 x 30。

可見通過安全左移，能夠大幅降低安全漏洞修復成本。

圖片來源：NIST

不同開發階段有不同風險漏洞，藉助各種安全掃描工具，層層遞進，才能實現整體，例如：

SAST - 靜態應用安全測試；
DAST - 動態應用安全測試；
IAST - 交互式應用安全測試；
RASP - 運行時應用自我保護；
Dependency-Scanning - 依賴項安全掃描；
Secrets Detection - 機密信息檢測。

圖片來源：Freebuf

DAST 和 SAST

今天，我們主要分享安全掃描工具之一——DAST（Dynamic Application Security Testing，動態應用程序安全測試）。

提到 DAST，就繞不開通常與其成對出現的 SAST（Static Application Security Testing，靜態應用程序安全測試）。首先，先釐清概念：

➤ SAST

通常在編碼階段，對源代碼進行安全測試發現安全漏洞的測試方案。

SAST 是對應用程序源代碼執行直接的白盒分析，分析是在代碼的靜態視圖上運行的，這意味着代碼在審查時沒有運行。

➤ DAST

在測試或運行階段，分析應用程序的動態運行狀態。它模擬黑客行為對應用程序進行動態攻擊，分析應用程序的反應，從而確定該 Web 應用是否易受攻擊。

DAST 是一種黑盒測試技術，它們不能訪問代碼或實現細節，只檢查系統對潛在漏洞測試的請求和響應。換言之，DAST 是外部的漏洞掃描程序。

另外，從掃描準備、掃描速度、開發語言等方面進行比較，兩者之間還有以下差別：

為什麼需要 DAST ？

從上文的內容中可以看到 SAST 具有其侷限性，包括：

SAST 應用於代碼未運行時，無法覆蓋運行問題或配置問題；
SAST 對於訪問控制，無法覆蓋身份驗證或加密等場景；
主流 SAST 工具均基於污點傳播模型實現，在代碼分支多、調用層級很深的情況下，信息網絡龐大（特別是考慮了調用順序和全局變量的情況下），耗時成倍增長；
為降低複雜度，檢查器丟失上下文信息，從而無法準確定位到某些標識符正確指向對象，最終導致誤報或漏報。

舉一個 SAST 誤報的例子。如下圖，這是一段 JS 代碼，定義了一個 test 函數，變量 b = 11 * 10，如果 b > 100 ，那麼返回一個普通字符串 safe；如果 b < 100 ，則將函數傳進來的實參去進行 eval。

我們肉眼來看，可以算出 b = 110 ，永遠都是大於 100，返回 safe 字符串，後面的 eval 永遠不會執行，所以這個函數在我們預想的運行情況下，它是一個安全函數。

但如果在極狐GitLab 上開啓 SAST 檢查，就可以掃到這個漏洞，如下圖，發現使用了 eval，認為有可能會導致危險的注入，進行警告，但實際上這個函數是安全的，因此產生誤報（在極狐GitLab 中，用户可以 dismiss）。

這個例子説明了 SAST 的侷限性。魚和熊掌不可兼得，因此需要 DAST 彌補一些 SAST 的不足。

DAST 的工作流程

以 Web 部署為例，DAST 的工作流程是：

Step 1 ：通過爬蟲掃描整個 Web 應用結構，爬蟲會發現被測 Web 程序的目錄數量、頁面數量、頁面參數；

Step 2 ：根據爬蟲的分析結果，對發現的頁面和參數發送修改的 HTTP Request 進行攻擊嘗試（掃描規則庫）；

Step 3 ：通過分析 Response ，驗證是否存在安全漏洞。

上述步驟涉及到兩種掃描方式，即：

被動掃描（default）：不主動攻擊，搜索 HTTP 消息、Cookie、存儲事件、控制枱事件和 DOM 以查找漏洞，包括搜索暴露的信用卡、暴露的機密令牌、缺少的內容安全策略以及重定向到不受信任的位置。
主動掃描（full）：主動攻擊，分析每個 HTTP 請求以獲取注入位置，例如查詢值、標頭值、cookie 值、表單和 JSON 字符串值，將攻擊內容注入到對應注入位置，形成新的請求，將請求發送到目標應用程序，並檢查 HTTP 響應來確定攻擊是否成功。

DAST 的優缺點探析

DAST 優點

1. 不受語言和框架限制

DAST 測試不要求具備編程語言知識；無論使用何種框架，DAST 工具都會根據輸入和輸出，評估應用程序行為。

2. 低誤報率

DAST 工具對應用程序環境執行端到端掃描，使安全研究人員能夠檢測和識別安全漏洞。

3. 無需訪問源代碼

DAST 掃描通過應用程序前端發送惡意有效負載來測試，因此企業可以利用第三方安全服務來執行，而不暴露應用程序代碼。

DAST 缺點

雖然 DAST 工具評估應用程序代碼中的各種漏洞，但它們無法定位代碼庫中安全問題的確切位置；也無法嗅探應用程序堆棧中未執行部分中的漏洞。

常見的 DAST 工具

下圖所示是常見的 DAST 工具：

極狐GitLab 中 DAST 流水線的流程

Step 1：因為 DAST 是黑盒測試，需要依賴於一個運行中的真實應用程序才能工作。因此，先準備一個已部署的應用網站（測試網站）；

Step 2：在倉庫 CI Yaml 文件配置對應 DAST 腳本

Step 3：把相應配置提交到對應極狐GitLab 倉庫，觸發流水線，通過 CI runner 運行掃描程序，模擬用户訪問請求；

Step 4：獲得響應結果，分支器會針對響應返回結果做具體分析，如果輸出有漏洞，則輸出到對應的漏洞報告中，該報告在 CI runner 運行完之後，統一輸出到 CI 產物中；

Step 5：根據漏洞報告展示的漏洞具體信息，開發者可以着手進行漏洞修復。

極狐GitLab DAST 配置指南

Web Analyzer

兩種類型的 Web Analyzer

實際開發中，以 Web 應用為主。極狐GitLab 針對 Web 應用提供兩種類型的 Analyzer ：Proxy-based analyzer 和 Browser-based analyzer。接下來分別介紹：

➤ Proxy-based analyzer: 用於掃描傳統的簡單 HTML 應用

在極狐GitLab 中配置 DAST 的 Proxy-based analyzer 非常簡單：聲明 DAST stages，通過引入一個模板文件，就可以開箱即用了。

在實際運行的過程中，調用 ZAP 代理程序，對應用程序進行一個掃描過程：

➤ Browser-based analyzer: 用於掃描重度使用了 JavaScript 的應用，包括單頁應用

Browser-based analyzer 使用瀏覽器模擬訪問：配置對應參數 DAST_BROWSER_SCAN，設置為 true，就可以啓用了。

它的原理是在 ZAP 前端設置了一層瀏覽器代理，模擬用户進行行為分析，通過 ZAP 代理，訪問到具體的 Web Application。這樣的好處是所有請求和返回結果實際上都是經過 ZAP，這樣可以利用 ZAP 的請求分析功能，對具體響應就做具體分析，看是否存在漏洞。

上圖配置中引用了一個模版配置文件：DAST.gitlab-ci.yml，它具體是做了哪些事情？如下圖：

聲明瞭需要引用的鏡像版本號：13；
聲明瞭一個新的 DAST 任務，使用極狐GitLab 官方提供的 DAST 鏡像，進行掃描處理；
可以看到具體的 script 參數裏面，先通過提取對應的環境變量 DAST_WEBSITE（如下圖方式1）或者把對應的地址放到根目錄下 enviroment_url.txt 文件（如下圖方式2），兩種方式取其一；
執行腳本，分析完之後他通過 artifacts，也就是對應瀏覽 Pipeline 產物；
最後將漏洞報告輸入到文件中去。

圖注/方式一：適合靜態地址