0X01 前言
怎麼衡量一個掃描器的好壞，掃描覆蓋率高、掃描快、掃描過程安全
而最直接的效果就是掃描覆蓋率高（掃的全）
怎麼掃描全面，1 流量全面 2 規則漏報低
流量方面上篇已經講過，這篇主要講掃描規則。
掃描規則漏報率低，從整體考慮，一方面是規則全，廣度上有保證；一方面是檢測手段有深度，可以跨能力聯動檢測，有能力解決主要和旁枝末節處的漏報場景
0X02 規則來源
掃描器的規則主要有兩種型別
針對介面的web漏洞，通常是通用型漏洞，OWASP TOP 10，sql注入、xss、ssrf、xxe等，以下簡稱web規則
針對主機(包括整個站點)的漏洞，通常是特定框架/應用/元件的0day/nday漏洞，以下簡稱主機規則。
2.1 主機規則
2.1.1 覆蓋nday
針對nday，主要考慮的是企業內資產。
在資產方面獲取到企業內所有IP與埠後，進行埠指紋識別（服務指紋識別/WEB應用指紋識別），根據每種指紋的數量排序，優先解決TOP100 / TOP 200 / TOP 500 的服務的歷史高危漏洞。
2.1.2 覆蓋新出的漏洞
針對0day漏洞，我們要解決的是新曝光的影響面較大的0day（很多情況下，新漏洞都是靠朋友圈/公眾號，這部分是隨人的，可能隨著人員流動、發現的敏銳度會變化，所以儘量做成自動化運營流程）。
這裡主要通過漏洞預警功能(或類似叫法)。
週期獲取cve漏洞列表，匹配內網資產，再檢測其他平臺是否有對應cve編號。優先判斷又有資產又有poc或exp的漏洞是否有影響，有較多資產代表影響範圍較大，有poc或exp代表外部大概率已經有人在掃描與利用了。
然後再判斷有資產的但沒有poc與exp的是否影響範圍較大，是否需要投入人力對漏洞進行研究（個人認為這是甲方的研究的一個需求，但是往往投入產出較低，所以需求較低）。
對應的功能是各家乙方的漏洞預警公告
阿里雲漏洞庫
騰訊雲漏洞掃描服務情報中心
如果短期無法進行流程建設，定期由運營人員去看一下這些列表，判斷資產匹配程度，有資產的漏洞編寫成外掛進行掃描，也可以有較好的收斂效果。
另外說一下資產指紋識別，理想情況下通過指紋識別打標，可以知道企業所有服務。但指紋識別有一個難點在於不知道有什麼資產，就寫不出對應的指紋規則。
所以需要有對應的打標流程，上文提過指紋打標，通過多特徵組合成規則的形式，完成一個打標功能建設。
打標的需求源頭，主要一方面就是漏洞預警，針對0day快速檢測對應服務的資產數量，否則內網幾十萬的機器量級，每次都花費數小時全部掃描一遍來判斷服務數量，影響漏洞響應時間（MTTR）。同時完善資產指紋，對資產較多的服務，歷史漏洞也處理一遍。
2.2 web規則
2.2.2 覆蓋場景全
web規則主要是針對通用型漏洞。
首先把場景儲存下來，以靶場的形式，可以週期進行驗證，驗證每個漏洞型別是否每個場景都能檢出。
靶場作為裁判員，安全產品作為運動員。
怎麼能找出所有的web通用型漏洞呢？
a. 漏洞型別
尋找各種同類安全產品支援檢測的掃描型別，從中排除掉危害較低的或者不存在於公司場景的
b. 每種型別的漏洞場景
常常有這樣的情況，有檢測sql注入、儲存xss的外掛，但是有些場景沒有顧及到，比如header裡的注入、post json中的注入等。
場景考慮齊全，需要針對每種漏洞抽取出維度，有一部分是公共維度，有一部分是私有維度，再進行維度相乘，得到最終各種場景。
舉個例子：比如注入有哪些型別和場景？
維度可以是 不同來源/不同過濾與防禦條件/不同執行方式/不同輸出方式等，而這些是公共維度，類比到其他漏洞型別也可以按這樣劃分；私有維度比如資料庫版本、資料庫報錯是否開啟等（單獨影響該漏洞場景）。
將每個維度的種種可能乘起來，得到各種場景，其中之一例如 來源於cookie+過濾了單引號+jdbc執行+無回顯+mysql5.7。
2.2.2 覆蓋新場景
主要是漏洞召回，來源如應急響應中心、等保測評、紅藍對抗等。
召回時排查全流程問題，流量有沒有進入引擎、是否繫結了對應的檢測規則、掃描過程的結果是什麼、最後結果有沒有入庫等。如果是規則問題，需要新增靶場
召回會有一部分原因是固定的無法快速解決的，比如流量缺失(post/cookie等)、檢測能力不足，召回一段時間後再重點推動解決導致漏報的大頭問題。
2.3 準確率保障：靶場
另外說靶場，這裡靶場是一個比較重要的安全產品
作為檢測能力的裁判員，主要的作用是
a. 將各種漏洞場景持久化沉澱下來，隨著召回不斷進行，場景也會越來越多
隨著人員流動，當初某個規則所用到的測試環境，可能會消失。交接人員對規則進行優化時，又需要重複測試環境搭建過程，成本較大。而把場景轉換成web程式碼場景、或者docker file沉澱下來，極大減小了優化過程的成本。
b. 衡量各種漏洞檢測安全產品的能力，給出準確率、漏報率等資料
規則的準確率，是提高且穩定漏洞產出的一個重要環節，在規則數達到幾百上千的情況下，每個規則是否有效，往往是編寫時候臨時做了驗證。
後期可能因為某些原因（比如造成了業務影響、導致引擎效能問題）下掉或者減少檢出場景，而忘了加回來丟在記憶角落裡。次數多了，整體場景檢出率可能很低，只有內網滲透召回時才發現那麼多漏報。所以準確率驗證十分有必要
c. 測試安全防護程式碼的可用性、有效性
安全防護程式碼是否有效，能防護住所有認知裡的場景，是否在壓測情況下對業務效能沒有過多影響，這是靶場的驗證效果。
整體來說，輔助功能比較大，極大的保證了每個規則的準確率，但直接產出可能不是很明顯，屬於發展到較為成熟時的能力。
0X03 檢測方式
3.1 跨能力聯動檢測
結合各種側通道功能，增強掃描能力
比如最常見的dnslog，命令執行時在伺服器上執行dns查詢，dns請求經過dns伺服器層層穿透到外網，再傳回給掃描器；根據dns標識，判斷具體的掃描任務觸發了。dns的特點在於可穿透不通網但不禁dns的場景，但無法鎖定觸發IP（一般為dns伺服器IP）。
再比如http log，curl/wget發起http請求，根據http請求中的標識判斷漏洞，無法檢測不出網的環境，但是可以鎖定訪問IP。部署在公網的http log，主要面對於儲存型xss這類請求可能是在外網觸發的。
針對命令執行類的，最好是用部署在內網的http log。dnslog偶爾會出現觸發了、但是和流量關係不大的問題，比如路由器不定時觸發、某業務收集映象流量並做了非同步流量處理的定時任務、某個測試收到請求後好奇請求了一次，會有溯源難的問題。http log剛好把內網IP鎖定，且ssrf也得使用內網http log。
java agent 探針，獲取執行層的函式與引數，像注入/任意檔案讀寫(寫crontab等命令執行來檢測有危害)這種也可以檢測出來。
或者是主機agent (HIDS) 監控主機特定檔案內容來判斷檔案操作
或者是sql日誌聚合彙總來判斷sql注入
另外檢測時避免造成業務影響，比如log4J的ldap連結不斷開可能導致業務hang住。
3.2 單一漏洞檢測能力深入
比如針對XSS，現有很多場景都是前後端分離。單純的 requests.get獲取頁面內容再正則匹配已經有點古老的。
使用headless瀏覽器解析JS。
監聽彈框事件，針對所有引數插入payload；或者作預處理，針對所有payload出現的位置構造特定的payload等。
3.3 豐富檢測所需流量資源
3.3.1 登入態
大多數檢測所需要的登入態，映象流量方案，無法使用使用者的cookie、header（業務自定義header可能帶有使用者登入憑證），所以得構造測試cookie。
在有所有業務統一接入passport的情況下（一個cookie或者token對所有業務生效），和passport申請介面更新cookie就好了。
有的業務接入passport會將passport認證對映到自己的使用者體系，登入passport後根據獲取到的token，在後端自己驗證所屬使用者後、賦予業務自己的賬號許可權。這種情況最好能找到passport下游接入呼叫方，統一更新對應業務的登入憑證。
而業務比較複雜、存在多種認證場景的情況下，比較麻煩。不同的域名或者子域名，需要定期的更新cookie。
這種情況需要一套自動登入程式，填寫賬號密碼，加上驗證碼自動填寫，獲取到cookie後到每個單位的驗證地址去驗證cookie有效性。通過不斷召回運營，豐富登入態。
3.3.2 字尾
正常情況下，流量過濾的步驟會過濾掉 js/css/zip/jpg/png等靜態資源字尾。
但是有部分漏洞需要這些字尾，得通過召回豐富待檢測資源。
比如 xxx.jpg?height=100&width=100，可能後端會根據引數構造返回包，會有dos的風險。
有的js檔案會洩露未授權的介面，WADL檔案存在介面洩露等
召回過程，會遇到很多流量缺胳膊短腿、任務丟失、核心請求函式不支援、檢測手段不足、檢測ROI低所以放棄等情況，路漫漫
0X04 總結
通過覆蓋現有的漏洞場景，建立未知場景運營流程，深入檢測手法、檢測資源，並使用靶場確保每個漏洞場景都可以有效檢出，可以做到保證整體覆蓋率。
且自研DAST在規則檢測上更貼合企業自身業務，更細、更全、更快。