DAST開發技術設計與分析

王寧 周云才

摘要：DAST作為自動化安全測試工具，是目前應用最廣發、使用最簡單的一種web應用安全測試方法，評價其優劣的重要一點就是發現漏洞的能力，而發現漏洞的前提是DAST前期爬蟲能爬取到的web資源多少，爬取頁面的能力越強，爬取到的資源越多，可發現漏洞的概率也將會大大提升。文章將從任務模塊、掃描模塊和爬蟲模塊三大核心模塊出發，講解DAST的實現原理、系統架構、核心處理機制，同時介紹了開發過程中碰到的問題和解決思路。

關鍵詞：動態應用程序安全測試;黑盒測試;動態爬蟲; 掃描引擎; 漏洞掃描

中圖分類號：TP311? ? ? ? 文獻標識碼：A

文章編號：1009-3044（2022）06-0065-03

開放科學（資源服務）標識碼（OSID）：

1 概述

DAST全稱為動態 web 應用程序安全測試，是一種基于黑盒式安全測試的技術，是目前國內應用最普遍、使用最簡單的一種動態 web 應用安全測試的方法，安全工程師常見的測試工具有諸如AWVS、AppScan 等，這些都是基于DAST原理的測試產品[1]，DAST作為自動化安全測試工具，評價其優劣的重要一點就是發現漏洞的能力，而發現漏洞的前提是DAST前期爬蟲能爬取到的web資源多少，爬取頁面的能力越強，爬取到的資源越多，可發現漏洞的概率也將會大大提升，隨著互聯網的開放性和自由性使得黑客更容易獲取到敏感信息，造成網絡安全問題的發生[2]。

2 DAST實驗原理

2.1 主要過程

通過爬蟲搜索來搜尋整個web的應用架構，發現一個被檢索web 應用程序包含了多少個目錄，多少個網站，頁面中所有元素都為參數;根據爬取的結果，對已經發現的網站頁面和參數重新根據規則內容組裝網站的結構，發送一個修改后的HTTP Request 進行了襲擊嘗試;通過對Response返回內容的準確性進行了分析和判斷，來驗證其中是否有安全漏洞。

2.2 系統架構

任務下發接口：在bs2系統中填寫相應待測域名及必要信息點擊下發或通過API接口提交。

漏洞展示接口：測試完成后相應漏洞信息會在bs2中詳細展示或通過API接口獲取結果詳情。

Celery任務調度：Celery架構主要由消息中間件（message broker）、任務實時執行消息單元（worker）和對每個任務消息進行實時執行的消息結果（task result store）等部分共同結合組成，可以大量處理實時異步信息。

Scrapy：Scrapy是一個快速的高級web crawling和web scraping框架，用于抓取網站并從其頁面中提取結構化數據。

Pyppeteer：Pyppeteer是Puppeteer的Python版本，Puppeteer語言是 google 基于 node. js 進行開發的一個軟件，可以通過Chrome瀏覽器的API以JavaScript代碼對Chrome進行簡單操作，用于爬蟲來完成對Web 程序的數據爬取和 Web應用程序的自動檢索測試。其API極其完善，功能非常強大。

awvs、xray掃描引擎：目前主流知名的web漏洞掃描器[3]。

Docker容器[4]：是一個基于開源軟件應用程序的軟件容器開發引擎，完全采用開源沙盒架構機制，相互之間沒有任何接口。不依賴任何語言、框架包括系統。

3 核心模塊

3.1 任務調度模塊

本項目將Celery分布式系統作為一個整體性的任務調度，它作為分布式任務團隊的異步處理框架，能夠使得任務的執行過程完全獨立于主程序，甚至能夠分配給別人去運行。Redis為Celery的broker，主動掃描、被動掃描、爬蟲、信息收集共4個節點的任務執行單位 worker 并發運行在Celery節點中，MangoDB為節點的任務執行結果存儲 task result store。周期地獲取url，從url相關的附屬信息中判斷該url即將進行的任務狀態，并根據任務狀態分配進行相應的動作，若沒有新的掃描url則等待。對于一些爬蟲引擎的分布式調度階段可能遇到的問題，在具體看到單個 browser 如何來管理自己所對應 tab 的時候，因為Chromium的啟動和關閉成本非常大，遠遠超過了標簽網頁 tab 的啟動和關閉，而且只有讓 browser 長時間駐留，才可將Chromium服務化，為了達到這個目的，在執行時，會涉及browser對tab動態管理的情況，本文主要采用的方法是 Pyppeteer，因為CDP中所有相關的操作均為異步，那么 browser 對 tab 的各種動態加權或者增減其實也就是等價于協工程任務的動態性增減。

對于這個問題目前的解決方案為：首先，要控制單個的browser能同時處理的tab頁面的閾值，因為單個browser其實是一個處理進程，而且在設置的最大tab數的數量過多時，會導致維持多個websocket的連接，當使用者的單個處理進程邏輯較復雜，單個處理進程的CPU占用就很有可能會達到一定的占用極限，相關的處理任務也可能會被直接阻塞，效率就可能會開始有所謂的下降，某些tab頁面甚至會由于超時自動關閉退出。所以單個的browser能同時處理的tab頁面必須控制到一個固定的閾值，這個閾值需要依靠CPU的占用情況及具體性能來決定。實現這種設計方法的主要目標之一就是通過自動創建一個新的事件任務循環，判斷當前的多個事件任務循環過程中的事件任務執行次數與最大任務閾值之間的最大差值，往其中一個循環新增的事件任務執行次數增加即可。同時，因為我們可能開啟了一個事件處理循環后對一個主運行進程的事件阻塞，我們可能需要自行監控一個特定時間點，該循環的事件運行也必須保證它本身是異步的，我們可能需要自行創建一個從它自己所在的一個事件處理循環中發出去向自己和它所在這個地區的異步事件并在循環中自行添加一個異步任務，圖3中所顯示的事件就是上文提到的運行順序和事件循環中的運行樣式截圖。

3.2 掃描引擎模塊

本項目使用的是開源的awvs、xray兩款主流漏掃來配合實現相關的掃描功能[5]。任務下發處提供主動掃描、被動掃描兩種方式，被動掃描的話是通過xray本身以被動方式運行，返回給前端代理的ip+port，此方式是便于安全人員自己使用及業務開發人員開發過程中自我進行相應安全檢測，xray獨立運行，結果會返回到前端展示。

主動掃描是以AWVS為主，AWVS輪詢檢測到掃描請求時，會創建新的掃描任務，同時將流量代理到xray的設置模式，與xray進行同步掃描，結果處理模塊會等待兩個掃描器全部完成掃描后對結果進行格式統一、去重等處理，最后完成入庫，由前端進行漏洞展示。

3.3 爬蟲模塊

爬蟲的整個模塊作為Celery中的一個worker單元，以Scrapy框架為核心[6]，通過Scrapy本身的spiders、engine、downloader等中間件來實現整個的爬蟲，而單靠scrapy無法實現復雜的動態爬蟲，所以在原有的下載器中間件管理器列表中加入了Pyppeteer來輔助實現動態爬蟲。

首先可以通過調用start_requests（）接收前端下發任務信息的數據庫，從而獲取相應信息生成第一個初始請求URL，并且指定一個parse方法的回調函數;在parse方法的回調函數中，解析響應出的內容并返回對象，在這些請求中還會包含一個回調事件處理這些響應;Scrapy Engine在其中作為引擎，負責其他所有中間件的信號、通訊、數據的傳遞等，生成的requests通過它發送給Downloader下載器去請求下載資源[7];在Downloader下載器中有下載處理器和下載器中間件管理器，其中下載處理器對所有引擎發送過來的requests進行處理，下載器中間件管理器會按照上圖順序自上而下處理，在最下方添加了Pyppeteer用來處理網頁中的事件，引擎將獲取到的Response交給Spider來處理，并獲取Spider解析后的request;只要有新的request，Scrapy的Engine與Scheduler模塊就會重復運轉，直到任務隊列中沒有新增為止。

整個的爬蟲模塊中最為重要的一個是處理動態爬蟲的部分。動態爬蟲作為漏洞掃描的前提，對于web漏洞發現有至關重要的作用，先于攻擊者發現脆弱業務的接口將讓安全人員掌握先機。即使你有再好的payload，如果連入口都發現不了，后續的一切都無法進行。

隨著靜態網站服務前端設計框架的廣泛使用越來越多，網頁內容對于網頁爬蟲也可能變得越來越不友好，在不斷地考慮如何重新進行網站服務端網頁渲染時，vue等前端框架可能會直接讓一些靜態網頁爬蟲完全的消失效[8]。在puppeteer和Chromium項目經歷了不斷迭代后，新增了很多關鍵功能，Headless模式現在已經能大致勝任掃描器爬蟲的任務。所以我們果斷選擇了py.ppeteer（采用python實現的puppeteer非官方版本）來實現動態爬蟲功能。 爬蟲在爬取頁面時，可能會被意外導航請求中斷，造成漏抓。所以除了和本頁面相同url的導航請求外，其余導航請求都應該被取消。避免造成漏抓，面對重定向需要根據具體情況來區別對待。

靜態爬蟲（如Scrapy等）通過解析form節點手動建立POST請求的方式，在現在已經稍稍落伍。當前互聯網的前端處理邏輯越來越復雜，復雜的JS邏輯處理充斥在頁面執行各個部分（如填寫表單、發出POST請求等），最后的請求內容格式和靜態構造差別巨大，總的來說，靜態爬蟲無法滿足大部分爬取需求，所以爬蟲必須模擬正常的表單填寫以及點擊提交操作，從而讓JS發出正確格式的請求，這樣才可以做到準確爬取。

表單的提交也有一些重要問題需要特別注意，如果直接點擊一個form這個表單的提交按鈕，那么就可能會直接導致當前的表單頁面重載，使用者可能不完全希望當前的表單頁面被重載，為避免這種情況，在hook前端導航請求之外，還需一個target屬性設置在form節點，指向一個隱藏的iframe，若想成功提交表單，還得正確觸發表單的submit操作。另外，不是所有的前端內容都有規范的表單格式，或許有一些form連個button都沒有，所以為了保險起見，只能盡可能地多嘗試幾種方法。

4 總結

4.1 目前DAST的優劣勢

DAST的主要優勢為：DAST可發現絕大多數常規的安全漏洞;DAST平臺可以解決大量L1、L2級域名系統無法人工安全滲透測試問題;DAST提供被動掃描功能，可方便業務開發人員自我進行安全檢測。

DAST的主要劣勢為：DAST的主要測試對象為http/https的web應用程序，但是對于IOS/Android上的App無能為力;DAST無法定位漏洞的具體代碼位置和分析漏洞產生的原因，僅能定位漏洞URL;DAST太過依賴自身漏掃功能，不能發現其他類型的安全漏洞;DAST運行需要發送漏洞攻擊包來進行安全測試，該方法會對業務測試造成一定的影響以及產生一些臟數據。

4.2 結束語

通過此篇文章，大致講解了DAST掃描的實現原理、系統架構、核心處理機制，對其中涉及的關鍵算法步驟都做了詳細分析，同時介紹了開發過程中碰到的問題和解決思路，希望能給閱讀者一些知識上的收獲。

參考文獻：

[1] 劉杰，葛曉玢.基于網絡爬蟲的Web漏洞掃描研究[J].黑河學院學報，2017，8（12）：211-212.

[2] 王小君.網絡信息安全防范與Web數據挖掘系統的設計與研究[J].電子設計工程，2018，26（12）：83-87.

[3] 牛詠梅.面向Web應用的漏洞掃描器的設計與實現[J].南陽理工學院學報，2018，10（6）：66-69.

[4] 董昕，郭勇，王杰.基于DevOps能力模型的持續集成方法[J].計算機工程與設計，2018，39（7）：1930-1937.

[5] 陸靜.10種漏洞掃描工具[J].計算機與網絡，2020，46（15）：30-31.

[6] 方奇洲.基于Docker集群的分布式爬蟲系統的設計與實現[D].武漢：武漢郵電科學研究院，2020.

[7] 杜鵬輝，仇繼揚，彭書濤，等.基于Scrapy的網絡爬蟲的設計與實現[J].電子設計工程，2019，27（22）：120-123，132.

[8] 徐鵬濤.基于Vue的前端開發框架的設計與實現[D].濟南：山東大學，2020.

【通聯編輯：梁書】