DAST 黑盒漏洞掃描器 第一篇：流量

掃描器已經接觸了三年，目前比較成熟，在這個方向里，遇到過很多問題，各種方案或多或少接觸過，大多數安全產品都可以用流量+規則+引擎+處置來抽象框架，DAST也是這樣，而功能，用目的劃分，個人拙見主要5個：流量全、規則全、引擎高性能高可用、掃描無害化、運營高效化，這個系列主要是對應功能的描述，

DAST流量主要以web應用(WEB流量以及對應API)和主機服務(HOST流量與域名流量)為主

1 WEB流量

web流量，即有哪些web漏洞

1.1 欄位

域名、路徑、get引數、post引數、headers；
回傳請求的header和body

1.2 來源

1.2.1 線上環境-流量鏡像

交換機處通過網卡采集流量，把由外部訪問的流量收集并轉發，
可參考 https://help.aliyun.com/document_detail/207513.htm
對應的流量型別還有由內到外的訪問，合并為南北向流量，
由內到外的流量通常用于IDS 入侵檢測系統，檢測對外訪問是否有木馬特征(心跳回連、DGA域名、發起IP較少等)，
東西向流量，即內網server-server流量，通常用于檢測內網橫向滲透的行為，
流量鏡像的特點是全，訪問的http流量都可以抓取，缺點也挺明顯

• 臟資料
  由于抓取的都是訪問的流量，那么就可能會帶來臟資料，
  比如，首頁登錄處獲取收集驗證碼，用戶A點擊一次獲取驗證碼后，斷斷續續收到十幾條驗證碼，感覺很莫名其妙，懷疑是網站泄露了手機號，代碼撰寫的在開發角度也挺合理，手機號作為GET引數傳入后端，沒有頻率限制，沒有token，收到請求就發送，當天用完即止，
  比如，作為開發，我用戶憑證的token不想放在cookie里，而是作為get引數，用戶新增了一個識訓地址，一天后發現地址串列里多了一百多條看不懂的地址，大為惶恐懷疑賬號被黑了，
  這是有增刪改的場景，
  單純的查詢也不是就沒有風險，比如，用戶訪問帖子、商品、文章等串列，掃描的時候觸發業務自己的風控，導致介面反爬機制對該用戶做了處置(封IP/驗證登錄等)，
• 資料量過大
  互聯網公司的每日訪問量一般超過百億，資料量背后需要一套聚合與去重的服務
• 缺乏https
  網卡抓取的流量鏡像一般是在請求決議前，所以https的流量還沒決議，目前https的比例越來越大，簡單的流量鏡像會導致這一塊的安全檢測都漏掉

1.2.2 線上環境-nginx流量

為解決https流量，可抓取nginx日志，決議后獲取流量，成本較低但不好控制 覆寫率有限(看運維這塊記錄的內容)

1.2.3 線上環境-WAF流量

WAF流量與鏡像流量相似，都是全面的流量，與鏡像流量不同的是，WAF通常是在nginx層后，可獲取https流量

1.2.4 線上/測驗環境-爬蟲

采用爬蟲模擬用戶操作抓取流量

好處：
采用自身測驗賬號抓取的流量，通常臟資料問題會比較少，因為這些請求都是正常用戶可以訪問到發出的，也是外部掃描器會收集到的，有問題的情況一般是業務存在漏洞、比如越權、注入、存盤XSS等，
缺點：

• 覆寫率問題
  采用基于無頭瀏覽器的爬蟲爬取的流量，可以實作js的決議，解決前后端分離（vue.js）等問題，能實作覆寫率90%，但是移動端APP流量的爬取還是個難題
• 研發成本
  爬蟲可能遇到訪問的時候中斷、卡住的問題，各種各樣的JS功能并不可預料，遇到例外情況需要適配優化，這方面需要持續投入
• 運營成本：cookie問題
  如果作為一個服務提供給業務使用，并沒有這個問題，而想要全面hold住，業務線很多，每個業務線下的業務可能需要的賬號權限都不一樣，即使有統一的passport，同一個賬號，這個業務有沒有開VIP，那個業務有沒有認證(用戶的實名認證、微信系結，商家的營業執照認證等等)，場景繁多，意味著需要一套持續維護的登錄服務，賬號、密碼、自動登錄的頁面和驗證碼破解，召回時不斷添加，實在繁瑣，運營成本極大
• 資源成本
  采用無頭瀏覽器模擬瀏覽器操作的pc web爬蟲、以及app爬蟲等，都極大的占用資源

1.2.5 測驗環境-瀏覽器插件

采用瀏覽器插件的形式，將訪問中的流量抓取下來，通過redis或者介面的方式發送給后端，再到引擎進行掃描，最后將結果回傳平臺；插件訪問介面做漏洞提醒，
單純的作為一個能力，提供給QA使用，QA控制流量開關
優點：簡單、可控
缺點：安全培訓的推廣，直接影響了整體使用率，在業務線不負責安全漏洞成本的情況下，推廣難度較大，

1.2.6 測驗環境-統一抓取

使用HIDS/IAST實作流量抓取，結合CI/CD平臺，在CD平臺上提供掃描能力，由QA自行開啟，
QA比較反感無感知的漏洞掃描，而且還用了QA的cookie，所以一定要站在QA角度 考慮QA的感受，
QA并不想在測驗的時候有較多的其他請求，所以不能實時同步掃描，QA也不想自己測完了，還要等待很長時間的安全掃描，所以不能做定時收集與掃描，最好的方式還是提供給QA能夠自己控制的安全測驗能力，在測驗結束后，可將這次測驗的流量投到DAST中，
掃描的時間視窗也要做限制，2-3分鐘內適宜，這就要求web掃描插件的時間需要控制在合適的范圍內，比如sqlmap做介面掃描方式可能不可行，超過時間視窗的只能丟棄或者以線上安全漏洞工單形式發送，
卡點：卡點功能最好也是由業務線可控，可以以報表的形式描述開啟率
如果能夠分辨增刪改流量，也可以將這部分流量是否掃描的控制交給業務

優點：作為一種能力提供給業務使用，QA可自行控制風險
缺點：理論上是可全覆寫的，初始階段因抓取服務的部署率和業務線合作程度，覆寫率會比較低，但這兩方面都可以通過技術手段以及運營推廣手段(漏洞成本轉移/安全培訓)提升

2 HOST流量

1.1 欄位

IP、埠、埠指紋、IP所屬集群(漏洞找人)、IP所屬業務線等

1.2 來源

內部平臺：IT資產資訊、運維CMDB、HIDS等
IP來源較為廣泛，有的時候較為復雜的內網，運維也無法清楚有多少IP，存在很多找不到人的IP
黑盒掃描：采用masscan+nmap的方式，做全網段存活主機發現、主機埠服務探測

內部獲取的資產資訊以及黑盒角度收集的資產資訊，是互補的兩個途徑，
通過兩種途徑結合起來的資產，往往會比內部其他平臺更全一些，

1.3 資產指紋

而HOST資產，最好還有打標流程，收集每個埠的指紋、http回應，將nmap的nmap-service-probes做成可配置的指紋檢測規則，掃描時判斷具體埠服務，各欄位匹配出多特征、多特征組合成打標規則，
一方面是0day出現時判斷影響范圍，另一方面是快速進行應急回應、漏洞掃描，

3 域名流量

域名是對外開放的一個口子，像一些框架漏洞、CORS，往往是整個域名都存在的、對域名下的每一條URL檢測效果都一樣，
這時候需要域名資產，
檢測時結合公網資產，對域名的埠進行掃描，在應急上ROI也比較高(一般0day爆發、外部漏洞掃描時，先用漏洞對企業所有域名掃一遍)

4 API

API是web流量的演化，如線上流量的去重規則到了較為成熟的時候，離線URL流量接近于企業的API，
對API作打標，結合SAST/IAST，判斷每個介面的操作屬性(增刪改查)、服務呼叫鏈、資料庫與表的呼叫，對于處理臟資料問題和資料安全問題都有比較好的輔助作用

標籤：訊息安全

上一篇：Base64隱寫

下一篇：基于數傳電臺的組態王控制實作遠程采集控制器PLC