王寧 周云才
摘要: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)編輯:梁書】