DAST開發(fā)技術(shù)設(shè)計與分析

王寧 周云才

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

關(guān)鍵詞：動態(tài)應(yīng)用程序安全測試;黑盒測試;動態(tài)爬蟲; 掃描引擎; 漏洞掃描

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

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

開放科學(xué)（資源服務(wù)）標識碼（OSID）：

1 概述

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

2 DAST實驗原理

2.1 主要過程

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

2.2 系統(tǒng)架構(gòu)

任務(wù)下發(fā)接口：在bs2系統(tǒng)中填寫相應(yīng)待測域名及必要信息點擊下發(fā)或通過API接口提交。

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

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

Scrapy：Scrapy是一個快速的高級web crawling和web scraping框架，用于抓取網(wǎng)站并從其頁面中提取結(jié)構(gòu)化數(shù)據(jù)。

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

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

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

3 核心模塊

3.1 任務(wù)調(diào)度模塊

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

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

3.2 掃描引擎模塊

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

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

3.3 爬蟲模塊

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

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

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

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

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

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

4 總結(jié)

4.1 目前DAST的優(yōu)劣勢

DAST的主要優(yōu)勢為：DAST可發(fā)現(xiàn)絕大多數(shù)常規(guī)的安全漏洞;DAST平臺可以解決大量L1、L2級域名系統(tǒng)無法人工安全滲透測試問題;DAST提供被動掃描功能，可方便業(yè)務(wù)開發(fā)人員自我進行安全檢測。

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

4.2 結(jié)束語

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

參考文獻：

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

[2] 王小君.網(wǎng)絡(luò)信息安全防范與Web數(shù)據(jù)挖掘系統(tǒng)的設(shè)計與研究[J].電子設(shè)計工程，2018，26（12）：83-87.

[3] 牛詠梅.面向Web應(yīng)用的漏洞掃描器的設(shè)計與實現(xiàn)[J].南陽理工學(xué)院學(xué)報，2018，10（6）：66-69.

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

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

[6] 方奇洲.基于Docker集群的分布式爬蟲系統(tǒng)的設(shè)計與實現(xiàn)[D].武漢：武漢郵電科學(xué)研究院，2020.

[7] 杜鵬輝，仇繼揚，彭書濤，等.基于Scrapy的網(wǎng)絡(luò)爬蟲的設(shè)計與實現(xiàn)[J].電子設(shè)計工程，2019，27（22）：120-123，132.

[8] 徐鵬濤.基于Vue的前端開發(fā)框架的設(shè)計與實現(xiàn)[D].濟南：山東大學(xué)，2020.

【通聯(lián)編輯：梁書】