甲方安全建設中有一個很重要的環(huán)節(jié)，即業(yè)務迭代上線前的安全檢測。大部分公司的產(chǎn)品研發(fā)部門都會配備一個或多個質(zhì)量測試工程師負責把關軟件質(zhì)量。

然而術業(yè)有專攻，質(zhì)量測試工程師能夠得心應手地應對軟件功能方面的缺陷，卻由于自身安全領域?qū)I(yè)知識的缺失導致很難識別安全風險。

針對這一問題常采用的做法就是由甲方安全人員定期對業(yè)務線進行安全檢查，但這種做法有很強的滯后性，一個業(yè)務從上線到被發(fā)現(xiàn)安全問題可能跨越了很長的周期。最理想的效果是在業(yè)務上線之前能夠?qū)踩L險“扼殺”，于是很多公司在業(yè)務上線會安排人工進行安全測試，但這種做法不夠節(jié)省人力。上述提到的兩個做法都有一定的弊端，一種更好的方案是在發(fā)布流程中加入自動化安全掃描，方案框架如下:

圖1. CI/CD中嵌入安全自動化

問題與挑戰(zhàn)

業(yè)務部門迫切希望安全團隊能夠在業(yè)務上線之初就發(fā)現(xiàn)安全問題， 但每天面對大量集成發(fā)布，安全人員在“人力匱乏”的情況不太可能都將人力參與進來。即便如此，保障公司幾百個業(yè)務系統(tǒng)的安全，仍然是我們團隊的重要使命。

安全團隊考慮在整個 CI/CD 流程中加入自動化安全檢測(分為白盒和黑盒,這里暫時只探討黑盒)。常見的做法是由安全團隊提供一個在線的 web 漏洞掃描器?，F(xiàn)代的 web 漏洞掃描器檢測原理如下:

• 使用網(wǎng)絡爬蟲(基于 chrome headless 或者 phantomjs )爬行 web 應用

• 對爬行到的接口進行安全檢測

在實際應用場景中，上述的做法仍然會有如下幾個缺陷:

• 無法爬取到需要人機交互的的接口

• 效率低下，每次迭代發(fā)布就要重新爬行全站檢測

發(fā)布流程中會有質(zhì)量測試工程師對業(yè)務中更新的接口進行測試。如果能夠抓取到測試工程師在質(zhì)量測試過程產(chǎn)生的流量并進行安全檢測，就能完美地解決上面提到的兩個問題。

業(yè)界常見的方式是利用網(wǎng)絡代理(通過配置瀏覽器網(wǎng)絡代理)捕獲流量再進行安全測試，這種方式具有可跨平臺的優(yōu)勢。中通安全團隊決定在利用傳統(tǒng)方式(通過配置瀏覽器網(wǎng)絡代理)的同時加入另外一種全新的方式-利用瀏覽器插件捕獲流量并作為和后端交互的媒介。利用瀏覽器插件比直接通過網(wǎng)絡代理具有如下優(yōu)勢:

• 客戶端調(diào)試更加方便 

• 測試時不需要為 fiddler 配置雙重代理

• 交互性好,可以給用戶下發(fā)桌面通知

• 結(jié)合服務端能夠檢測存儲型 xss 的優(yōu)勢

下面會講解這種方式具體的實現(xiàn)細節(jié)。

Hunter架構(gòu)

系統(tǒng)定名為 hunter，寓意是能夠像獵人捕獲獵物一樣敏銳地發(fā)現(xiàn)漏洞。服務器端持久化存儲使用了 mysql 數(shù)據(jù)庫，消息隊列選擇 rabbitmq，在掃描結(jié)束之后會發(fā)送提醒通知。整個掃描器架構(gòu)設計如下:

圖2.hunter架構(gòu)圖

瀏覽器

用戶新建任務時，需要對瀏覽器插件中的抓取規(guī)則進行配置，配置完成之后會將用戶的請求流量發(fā)送到 API(Application Programming Interface, 應用程序編程接口)，為  hunter 安全檢測提供數(shù)據(jù)源。

API

主要包含接收瀏覽器發(fā)送的流量、sso 中心鑒權(quán)、創(chuàng)建停止任務、將捕獲而來的流量推送到消息隊列、提供掃描結(jié)果。

消息列隊

由于 sql 注入檢測和 xss 檢測需要較長的時間，故使用 rabbitmq 提供的 Fanout Exchange 模式綁定到多個 queue。sql 注入檢測和 xss 檢測的 queue 被專門的 consumer 進行消費。

分布式檢測引擎

采用分布式部署方案，可以部署多個消費節(jié)點。消費節(jié)點從 queue 中消費到流量之后進行單 url 多 poc 的檢測方式。

通知

檢測引擎在執(zhí)行完成之后會對使用者進行郵件、釘釘、微信等方式的通知。

可視化平臺

在 hunter 的最初版中，掃描報告只會在檢測引擎執(zhí)行完成之后通過郵件發(fā)送。質(zhì)量測試同事反映日常工作郵件太多很容易堆壓掃描報告郵件，希望我們提供一個平臺展示用戶的所有歷史任務和安全掃描報告。

主要模塊分為四個部分：QA 人員、瀏覽器插件、RESTfulAPI、分布式分析檢測引擎，各模塊之間的詳細交互流程如下:

圖3.hunter使用流程參與角色和架構(gòu)

后續(xù)的開發(fā)進度和思路也是依據(jù)此圖展開，下面將分析各個模塊，并重點講解瀏覽器插件和分布式分析檢測引擎的實現(xiàn)(姑且將瀏覽器插件稱為客戶端，以下都以 chrome 插件為例)。

具體實現(xiàn)

客戶端

結(jié)合上圖3分析可知，在每次新建任務時，用戶使用客戶端會在當前網(wǎng)頁彈出用戶協(xié)議。用戶需要在閱讀協(xié)議并同意授權(quán)之后才能新建掃描任務。

彈出用戶協(xié)議

客戶端要想在當前網(wǎng)頁窗口彈出用戶協(xié)議，必須要獲得整個頁面上下文。翻閱 Google Chrome Extensions 文檔可知，在 content-script.js 中可以實現(xiàn)這個功能。實現(xiàn)思路比較簡單:在 content-script.js 中可以通過 $("html")直接增加對話框并顯示。

設置信息

除此之外，用戶在每次掃描開始之前需要配置一些基本信息:正則匹配規(guī)則(抓取哪個域名下的請求)，任務名和抄送郵箱(掃描結(jié)束之后會抄送郵件通知)。因為一次掃描過程的接口范圍可能是未知的(大部分情況下，A 域名系統(tǒng)只會調(diào)用 A 域名下的接口，但是還有可能 A 域名系統(tǒng)調(diào)用 B 域名接口，這點可能是用戶提前未知的)，所以需要每個新任務的正則匹配規(guī)則是可以動態(tài)設置的。 

抓取請求

可以在 background.js 中調(diào)用 chrome.webRequest.onBeforeRequest 和chrome.webRequest.onBeforeSendHeaders 來抓取 chrome 的網(wǎng)絡請求。(具體做法可以參考 https://developer.chrome.com/extensions/webRequest)

這里需要注意的是任何函數(shù)在 background.js 只要被調(diào)用，就會一直常駐在 chrome后臺。所以在用戶點擊停止任務之后，客戶端一定要移除監(jiān)聽器。content-script.js 和background.js 之間的通行可以通過 chrome.runtime.sendMessage 函數(shù)。

RESTful API

客戶端將捕獲到的網(wǎng)絡請求封裝之后會發(fā)送到 RESTful API 服務端，服務端會解析請求并判斷請求中的待檢測接口是否屬于合法白名單范圍(例如白名單為測試環(huán)境網(wǎng)段，防止向生產(chǎn)環(huán)境寫入臟數(shù)據(jù))。在通過白名單檢測之后，會推送到 rabbitmq 中等待分析引擎節(jié)點消費。

分析檢測引擎

在每次新建任務時，客戶端會向 RESTful API 發(fā)送一條包含新建任務標識和正則匹配規(guī)則的消息。同理在每次結(jié)束任務時也會發(fā)送一條帶有結(jié)束任務標識的消息。分析檢測引擎在消費到結(jié)束任務標識之后會通過郵件等方式通知相關人員。

因為 sql 注入檢測和xss檢測相對需要較久的時間，所以決定通過Fanout Exchange模式綁定到單獨的 queue。通用類的漏洞（大型 CVE、服務弱口令等）檢測往往不需要太久的時間，可以直接放入到一個 queue。整個掃描引擎是采用 POC 插件形式，在后續(xù)漏洞檢測拓展方面比較靈活。網(wǎng)上關于此類的文章很多，這里不做展開。我將會重點講下檢測存儲型xss方面的思路。

反射型/DOM 型 xss 檢測可以利用后端的 chrome headless 進行檢測。檢測 xss 的思路為:

• 監(jiān)聽頁面的彈窗事件

• 查看頁面中是否有新建立的標簽

具體的實現(xiàn)由于篇幅較長，網(wǎng)上也有很多資料，故這里不打算展開。豬豬俠在先知白帽大會分享的 web2.0 啟發(fā)式爬蟲實戰(zhàn)詳細地提到過檢測反射/DOM xss 檢測原理。

圖4.chromium檢測反射/DOM型XSS的具體方法

反射型 xss 的輸入和輸出在同一個網(wǎng)頁中，可以直接構(gòu)造檢測。但是對于存儲型xss (這種輸入和輸出位置分開的情況)直接檢測并不一帆風順，難點在于 xss 檢測引擎并不知道具體的輸出位置?？梢岳每蛻舳耸菫g覽器插件這一特性，讓其具備檢測 xss 的能力。

客戶端(瀏覽器插件)除了具有捕獲網(wǎng)絡請求并發(fā)送到服務端 RESTful API 的功能，還有另外一個功能就是檢測當前網(wǎng)頁中是否觸發(fā)了 xss?？蛻舳藭シ治鲑|(zhì)量測試工程師打開的網(wǎng)頁中是否觸發(fā)已經(jīng)提前構(gòu)造的(由后端的 chrome headless 檢測時插入的污染字符)payload?？蛻舳嗽跈z測到 payload 之后會向 RESTful API 發(fā)送一條檢測到xss的消息，其中包含具體的輸入位置( payload 中包含輸入請求的 requestid)。

通過 chrome headless 后端檢測反射性/DOM型 xss，客戶端檢測存儲型 xss 這兩種方式可以基本覆蓋到所有xss類型的漏洞檢測。

既然客戶端是基于瀏覽器插件開發(fā)而成，那么將賦予了我們更多的想象力和可能性。這里腦洞開一下，比如在檢測到漏洞之后利用插件自動截圖或者生成小視頻并發(fā)送到服務端進行保存，以便后續(xù)更加方便的復盤、查閱。

在每次新建任務的時候，用戶需要配置正則抓取規(guī)則、抄送郵件、任務名稱。

圖5.客戶端新建任務時的配置

配置完成之后，質(zhì)量測試工程師進行正常的接口測試即可。在每次掃描結(jié)束之后，用戶可以自行登錄 hunter 后臺進行查看歷史掃描記錄。如果質(zhì)量測試同學對漏洞信息感興趣，可以單獨查看每一條漏洞詳細信息。

圖6.一次掃描記錄

圖7.漏洞詳情

圖8.統(tǒng)計報表

總結(jié)和展望

Hunter 現(xiàn)已開發(fā)完成并在公司內(nèi)部推廣使用，同時發(fā)現(xiàn)質(zhì)量測試工程師在檢測出漏洞之后會表現(xiàn)出前所未有的亢奮(陰險臉)。

目前 hunter 能夠發(fā)現(xiàn)除越權(quán)漏洞之外的所有常見 web 漏洞(關于越權(quán)檢測我們團隊有一些想法正在實踐，如果您有興趣的話可以投簡歷，加入我們團隊和我們一起探討哦！)。未來的工作是不斷增加掃描插件、加強線上運營、結(jié)合內(nèi)部權(quán)限系統(tǒng)進行越權(quán)漏洞方面的檢測。希望能夠通過多種維度的掃描和檢測盡可能將安全風險在上線之前扼殺。很多質(zhì)量測試同事在使用 hunter 發(fā)現(xiàn)漏洞之后對信息安全興趣高漲，我們也會挑選經(jīng)典的案例整理成wiki提供給感興趣的同事查閱。未來我們計劃將 hunter 系統(tǒng)開源，希望能夠幫助到更多的企業(yè)。

參考鏈接：

Chrome extensions 開發(fā)文檔:

https://developer.chrome.com/extensions/webRequest

WEB2.0 啟發(fā)式爬蟲實戰(zhàn):

https://xzfile.aliyuncs.com/upload/zcon/2018/11_WEB2.0%E5%90%AF%E5%8F%91%E5%BC%8F%E7%88%AC%E8%99%AB%E5%AE%9E%E6%88%98_%E7%8C%AA%E7%8C%AA%E4%BE%A0.pdf