去哪兒網
去哪兒是全球最大的中文在線旅行網站,創立于2005年。去哪兒網為消費者提供國內外特價機票、酒店、旅游度假、景點門票產品一站式預訂服務,為旅游行業合作伙伴提供在線技術、移動技術解決方案。去哪兒近年來,接連發力大數據與人工智能,利用出游、住宿等領域的全量數據和人工智能,為用戶打造智能化搜索、排序、推薦等服務。目前,去哪兒用戶累計超6億,平臺年交易額超1600億,且仍在快速發展中。
作為洞態 IAST 最早期版本的用戶,去哪兒在 IAST 與其 Q-SDL 安全體系的融合適配上有著獨到的見解,十分感謝去哪兒 Q-SDL 負責人耿師傅對本次 IAST 實踐的分享。
一、安全背景
1. 新政策、新業務、新威脅
近年來,國家愈發重視信息安全,《網絡安全法》、《數據安全法》、《個人信息保護法》相繼出臺并施行,對互聯網企業提出了更嚴格的安全要求。在業務上,互聯網企業的業務邊界不斷拓寬,用戶和年交易額等均實現持續發展,業務保障需求更強。但技術研發成本不斷攀升、盈利增速下降都促使著以業務為主的企業,更加注重在安全上的“高產出”。據可查數據,自疫情爆發以來,黑客針對國內互聯網企業的攻擊幾乎呈現指數級增長,企業面臨的安全威脅極大。
在這樣的背景下,互聯網企業的網絡安全能力建設,尤其是應用開發期的安全能力建設顯得格外重要。阿里、騰訊、字節、去哪兒、輕松籌等企業均在著力強化應用安全開發,試圖在應用開發期便大幅降低安全風險。DevSecOps 流程、SDL 流程在各企業都已早早落地實踐運行,并打造適配其業務場景的安全體系。
2. 安全需求
去哪兒結合自身實際,打造了Q-SDL體系。Q-SDL體系通過預防、檢測和監控措施相結合的方式,減少設計、開發中的軟件的漏洞數量和嚴重性問題,降低應用安全開發和維護的總成本,保證系統的安全性。
從上圖可知,用于安全漏洞檢測的自動化工具僅包括 SAST 和 DAST,但 SAST 和 DAST 均具有不可避免的嚴重缺陷。
我們在實際運行中發現,白盒測試存在誤報率高、審計時策略規則失效明顯、掃描效率低下嚴重阻礙開發節奏等問題,尤其是無法獲取漏洞數據對安全部門造成了很大困擾。而黑盒覆蓋范圍有限,覆蓋率依賴于 Explore 的結果,無法掃描 AJAX、CSRF Token、驗證碼等頁面,無法測試 APP,無法定位漏洞的具體代碼,需要花費較長時間與人力來進行漏洞定位與原因分析。
去哪兒急需一款能夠彌補黑盒和白盒不足的產品來完善 Q-SDL 體系。
二、調研之路
考慮到開源產品具備高擴展性、低使用成本的特性,我們首先將選擇定位在開源產品上。由于當時市面上只有開源的 RASP,而沒有開源的 IAST,因此首先調研的是 RASP。但調研后發現 RASP 存在嚴重影響服務器性能的問題,恰巧在了解 RASP 的過程中,發現火線安全正在研發 IAST,并打算開源發布,于是便進行了接觸。以下為洞態 IAST 調研結果:
IAST 全稱交互式應用程序安全測試,主要通過 Agent 來收集和監控應用程序運行時的函數執行及數據傳輸,并與服務端進行實時交互,進而更高效、更準確的識別應用軟件的安全缺陷及漏洞。同時可準確定位漏洞所在的代碼文件、行數、函數及參數,方便開發團隊修復問題,還具備高低誤報率、0臟數據的優勢。但 IAST 在不同語言開發的 WEB 應用中需要有不同類型的 Agent、研發的技術難度和投入都非常巨大。
洞態IAST產品架構:
在調研中我們發現洞態 IAST 在架構上完全不同于其他 IAST,其他 IAST 往往 “重 Agent 端、輕服務端”,而洞態的 Agent 端僅用于實現數據監聽,漏洞檢測全部在服務端完成。這種方法的好處是 Agent 端代碼和邏輯簡單,單點故障率更低也極少需要升級,降低了維護成本;另外,傳統 IAST 產品對于當時未檢測的漏洞都在 Agent 端直接丟棄,產品出現新的檢測策略后,需要重新發起應用的測試,而洞態 IAST 將檢測數據保存在服務端,可輕松地在服務端進行回歸測試。
產品架構說明:首先,在服務器上安裝 IAST Agent。當 IAST 啟動,用戶訪問 Agent 服務后,Agent 便開始采集數據,并與 OpenAPI 服務通信,進行上報數據和Hook規則的拉取。OpenAPI 將數據存儲到數據庫中,包括 MySQL 和 Redis。然后,Agent 對 Engine 發送通知,Engine 便會來消費數據庫中的數據,并在分析完畢后將漏洞信息回寫到數據庫中。最后,用戶通過 WebAPI 查看數據庫中漏洞的數據信息。
洞態IAST檢測原理
洞態基于“值匹配算法“和”污點跟蹤算法”對漏洞進行檢測。這種算法檢測準確率高,還無需采集和重放流量,可以適配如今各種場景下的漏洞檢測(如 API 網關、分布式、微服務等架構下的后端服務漏洞檢測),還不會產生臟數據,干擾正常的開發測試流程。
對于檢測發現的漏洞,洞態根據外部可控數據的傳播過程,完整的還原漏洞觸發流程,幫助 DevOps 團隊快速理解漏洞、定位漏洞,更好的解決漏洞。通過賦能研發人員,提高漏洞修復的效率。
洞態IAST產品優勢:
? 第三方開源組件漏洞分析
? 應用漏洞溯源、定位與分析
? 應用漏洞自動驗證
? 全面的風險監測
? 開源帶來低成本、高擴展、多策略和多場景
促使我們選擇洞態IAST的原因,除以上產品優點外,還有洞態團隊對IAST部署升級的全力支持。在服務上,如果我們選擇其他廠商的RASP/IAST,不一定能得到全力支持。
三、IAST實踐
去哪兒部署洞態IAST已經有一年多的時間,特分享一下IAST實踐經驗。
IAST應用于Q-SDL體系
在 Q-SDL 體系中,IAST 承擔測試的角色,并且打造了 IAST 平臺收集漏洞信息數據。
部署適配
在 Q-SDL 體系中部署 IAST,主要是從基礎環境、應用環境、生命節點上進行適配,并在具體的點上進一步優化。
在去哪兒,IAST Agent 的部署環境包括容器與虛擬機二種。采用分布式部署的方式,提高系統的可靠性與可用性,并對二種不同環境開發一套標準流程,保證 Agent 在不同環境的標準化部署。部署完畢后,需要將安裝 Agent 的機器所在的網絡和 Agent 接收數據的 OpenAPI 之間的網絡打通,使 OpenAPI 能接收數據。
在實際應用上,通過二次開發,擴展 IAST 的功能,并推動和去哪兒其他安全工具的融合。通過洞態 IAST Agent 收集識別企業資產,從而對整個資產進行漏洞檢測。為應對 IAST 運行過程中可能出現影響業務等問題,我們提出了二套解決方案。一是“軟著陸”,即通過洞態 IAST 自帶的解決方案,直接刪除核心模塊;二是“硬著陸”,基于去哪兒強大的 API 直接將 IAST Agent 端去除。但我們使用這么長時間,還沒出現過嚴重的問題。
在使用中,我們并不是將 IAST 孤立地用來檢測。而是把威脅信息和項目信息,上傳至去哪兒的威脅建模平臺,然后將 IAST、DAST 和 SAST 做相應的配合,有針對性地檢測某些漏洞,提高檢測率。
私有云部署場景
對于私有云部署場景,我們主要做了二點變動:第一點是在 IAST Agent 部署時,把 Agent 包直接放入鏡像指定目錄,以應對龐大的測試流量。另一點是對 Agent 端啟動命令進行植入,以適配標準化環境,從而有序地執行,不去搶占其他環境變量的資源,發生沖突。
整體部署方案
整體的部署方案是遵循洞態 IAST 的基礎部署方案,我們只做了微調。業務端 Agent 沒有做太大的改變,僅對 Java 包進行了二次開發。為防止應用高流量高并發導致 IAST 超載,針對性地開發了負載均衡功能。而在 IAST 分析模塊上,我們將 Redis 獨立出來,并做得更強大些以應對高流量高并發。
以下為我們去哪兒網絡進出口的真實情況:
為控制突發性的高流量,我們采用了 “自適應流量采集+分布式架構” 的方案。自適應流量采集將無效的流量過濾,分布式架構則可靈活支撐高并發,減輕流量壓力。
運行流程
實際使用感受:
1. 值得稱贊的點
● 應用威脅識別廣泛
我們在上線前利用靶場做過了大量測試,才放心將洞態IAST上線。IAST檢測到的漏洞類型幾乎覆蓋所有的通用漏洞,包括(持續增加中):
● 組件威脅識別率高
IAST上線后發現了大量的組件威脅,具體數量等信息就不方便透露咯。
● 技術真材實料,服務盡心盡力
2. 吐槽
● 高危漏洞檢出率較低
洞態說明:因為去哪兒部署的是最早一版的洞態,出于穩定性考慮,還未進行版本更新,因此在檢測能力上相對新版本會差許多。但洞態會加強研發力度,持續擴大可檢測漏洞類型以及高危漏洞的檢出率。
洞態:去哪兒的 IAST 實踐亮點在于擅長將 IAST 與自身 Q-SDL 體系的適配,也善于從自身所處互聯網行業高流量高并發的特點出發,通過開發負載均衡功能、對 IAST 模塊進行調整、擴展開發等手段,將 IAST 的作用發揮到極致,也希望大家都能從去哪兒的安全智慧中找到靈感。
關于洞態 IAST
洞態 IAST 是全球首個開源 IAST ,于2021年9月1日正式開源發布。洞態 IAST 專注于 DevSecOps,具備高檢出率、低誤報率、無臟數據的特點,幫助企業在應用上線前發現并解決安全風險。自開源發布以來,洞態 IAST 備受開源社區人員和企業的關注,包括工商銀行、去哪兒、知乎、同程旅行、輕松籌等在內的上百家企業都已成為洞態用戶。
