攜程安全自動化測試之路

一、背景

業務代碼上線前，通常會在測試環境經過一系列的功能測試。那麼，從安全層面來說，web應用常見的web漏洞，如sql注入，xss攻擊，敏感信息泄漏等，我們如何保證在上線前就能夠自動化發現這些業務的安全漏洞呢？本文將詳細講述攜程安全測試的自動化之路。

二、技術選型

市面上也有很多各種各樣的開源、商業掃描器。單就應用這一層來說，漏洞掃描器一般分為主動掃描和被動掃描兩種。

其中，主動掃描一般用於黑盒測試，其形式為提供一個URL入口地址，然後由掃描器中的爬蟲模塊爬取所有鏈接，對GET、POST等請求進行參數變形和污染，進行重放測試，然後依據返回信息中的狀態碼、數據大小、數據內容關鍵字等去判斷該請求是否含有相應的漏洞。

另外一種常見的漏洞掃描方式就是被動掃描，與主動掃描相比，被動掃描並不進行大規模的爬蟲爬取行為，而是直接通過捕獲測試人員的測試請求，直接進行參數變形和污染來測試服務端的漏洞，如果通過響應信息能夠判斷出漏洞存在，則進行記錄管理，有人工再去進行漏洞的復現和確認。

所以我們可以發現，主動掃描與被動掃描最主要的區別為被動式掃描器不主動獲取站點鏈接，而是通過流量、獲取測試人員的訪問請求等手段去採集數據源，然後進行類似的安全檢測。

除此之外，基於主動掃描的web掃描器還有其他的不足：

1. 由於數據源來自爬蟲爬取，獨立的頁面、API介面等就無法覆蓋，存在檢測遺漏情況。
2. 如果是掃描單獨的幾個站點，主動掃描是夠用的。但是在站點數量急劇增大的時候，主動掃描的效率、精準、速度都無法與被動掃描相比。

最終我們選擇基於被動掃描的形式去實現自研web漏洞掃描器。

三、架構設計

基於以上自動化的安全檢測需求，由我們內部研發了Hulk項目，通過網路流量鏡像等方式來實現分散式的實時Web漏洞掃描系統。整個項目按模塊可分為數據源，數據處理，漏洞檢測，漏洞管理等幾大模塊。

如圖所示，Http請求數據從數據源發送至Rabbitmq、Kafka等隊列。交由統計、去重、去靜態資源模塊利用redis進行數據處理，處理後的unique請求存入Rabbitmq掃描隊列，等待scan engine的消費。而scan engine則全權負責參數解析和變形，利用預先設置好的規則順序進行請求重放和漏洞檢測。最終，如果Scan engine判斷出某個請求含有漏洞，則落地到MySQL中，交由Hulk的運營人員進行漏洞的確認和復現。

四、數據源

數據來源主要有2種類型，即基於網路流量鏡像的方式和基於Http代理的方式。

基於網路流量鏡像的方式中，需要在辦公網到測試環境核心交換機上做流量鏡像，通過dpdk、pf_ring等高速抓包模塊進行流量獲取，並按照五元組信息進行tcp流重組。然後通過http解析器，將其中http請求的請求方法、請求地址、請求域名、請求參數等數據提取成json格式，發送到kafka中。

當然，這其中還有一部分為https的請求，需要通過rsa key解密後才能交由http解析器正常解析。隨著http2.0時代的來臨，大部分的https請求在進行秘鑰交換時採用了更高安全性的Diffie-Hellman秘鑰交換演算法，我們的https解密模塊也逐漸退出歷史舞台，只能後移流量鏡像模塊，轉向純Http的流量捕獲。

基於Http代理的方式中，只需要配置代理伺服器，將測試人員的測試請求數據收集起來，然後採用同樣的模塊進行去重和統計處理，結果發送至Kafka隊列，有著與基於流量的形式同樣的處理流程。

五、數據處理

流量進入到消息隊列之後，去重模塊會從消息隊列消費，計算出url、args等的MD5值，在redis中進行去重，如果是一個已經掃描過的地址，則只記錄一條日誌到ES中;如果是一個新的URL地址，就將其具體的HTTP請求發送至消息隊列中，等待scan engine的消費。

在數據處理的時候，去重是非常重要的，這裡涉及到不同請求方法、不同的參數，任何一點不同，都可以被看重是不同的URL地址，也對應了不同的後端介面。

除了這些之外，針對偽靜態URL，我們也需要將/products/655554.html歸一化為/products/NNNNN.html。如上圖所示，將數字歸一化來去掉30%左右的相似URL。然後利用redis的TTL特性，使得一段時間之前掃過的URL，可以在下一次的去重中被判斷為新URL，從而再次加入掃描隊列，等待新一輪的安全檢測。

六、漏洞檢測

掃描引擎從消息隊列中讀取去重後的流量數據，使用多種不同的方式去進行漏洞掃描。

1. 一般的web漏洞配置規則來檢查，比如xss漏洞， 文件包含漏洞，敏感文件讀取等，先替換參數，或重新構造URL， 再重放， 再檢查響應內容是否包含特定的信息， 以此來判斷是否存在漏洞；
2. sql注入漏洞則使用高效的開源工具sqlmap來檢測，避免重複造輪子；
3. 另外還有一些其他漏洞，比如存儲型xss，struts漏洞，ssl的漏洞，這些無法使用簡單的替換參數重放的方法，但是我們提供了插件編寫功能，這樣可以讓運營人員寫插件，以滿足各種需求。

但是，從storm實時攻擊檢測系統過來的流量是不帶cookie的， 如何掃描登錄後漏洞呢？我們生產url和測試url可以通過一種映射關係進行轉換，保存各個測試站點的登陸信息文件。當讀取一個生產的url後，去獲取它的測試地址和登錄信息，就可以去掃描它相應的測試地址了。這樣就避免了影響線上用戶。

掃描速度也是掃描任務的一個關鍵指標，在整個架構中，不同的模塊之間是通過消息隊列進行數據傳輸的。所以當去重模塊或者掃描引擎模塊處理速度不夠快，造成數據積壓時，我們可以通過增加模塊實例來進行水平拓展。

七、漏洞管理

對於掃描結果中存在問題的URL和對應漏洞，我們會進行一個快照功能。即將當時的請求和響應包完整保存下來，方便運營人員驗證漏洞。

且對於響應體內容，還可以進行一個基本的本地渲染，復現漏洞發現時的真實情況。

八、規則測試

同時，為保證規則有效性，我們還在管理控制台中集成了規則的測試功能：

這樣，只需要搭建一個帶各種漏洞的測試環境，規則運營人員就可以在這裡配置， 然後針對性地對每一個規則、插件進行有效性測試。

九、總結

目前，整個項目上線穩定運行兩年多，已發現線上高危漏洞30+，中危漏洞300+，低危漏洞 400+，為線上業務安全運行提供了強有力的保障。當然， 對於數據污染、掃描頻率、去重邏輯、掃描類型等掃描器常見的詬病，我們後續也會一直不斷進行優化迭代。

【作者簡介】陳瑩，攜程信息安全部安全開發工程師。2013年加入攜程，主要負責各類安全工具的研發，包括線上日誌異常分析，實時攻擊檢測， 漏洞掃描等。

沒看夠？更多來自攜程技術人的一手乾貨，歡迎搜索關注「攜程技術中心」微信公號哦~

推薦閱讀：