對web網站、應用等系統進行掃描，從而提早發現更多的安全漏洞，是保護系統不可缺少的手段。一般的web安全掃描大多使用web掃描器，掃描器利用爬蟲技術，對目標系統進行資源遍歷并檢測代碼等來發現漏洞，一方面可以減少人工檢測的工作量，另一方面誤報和漏報也比較多。原因之一是爬蟲無法檢測一些隱藏較深的系統資源(比如：深層的URL)。這篇文章，筆者主要想和大家探討減少誤報漏報的一個思路。

設計

開始探討之前，我們先了解一下web漏洞掃描的一般過程和原理，大致分2種：

web掃描器：

利用爬蟲獲取目標系統的所有URL，再嘗試模擬訪問這些URL獲取更多的URL，如此循環，直到所有已知的URL被獲取到，或者利用已知URL列表對目標系統的URL進行窮舉，從而獲取有效的URL資源。把獲取的URL去重后，利用已知漏洞的檢測代碼對這些URL進行檢測，以判斷目標系統是否存在漏洞。

人工檢測：

通過設置代理(如：burp)來截獲所有目標系統的訪問請求，然后依據經驗對可能存在問題的請求修改參數，或者添加檢測代碼并重放(如：burp中的repeat功能)，從而判斷目標系統是否存在漏洞。

web掃描器可以極大的減少人工檢測的工作量，但由于爬蟲的局限性容易導致誤報和漏報；而人工檢測可以很好的保證準確性，但依賴于檢測人員的經驗和精力，尤其是大型系統，很難在有限的時間內完成檢測，同樣會造成誤報和漏報。那么，假如能有效地利用掃描器的處理速度又兼顧人工的精準度的話，是不是就可以很好地解決誤報和漏報了呢？我們不禁思考，如果有辦法可以獲取到所有的真實請求(包括：請求頭，cookie，url，請求參數等等)并配合掃描器的檢測代碼是不是可以更有效的對系統進行漏洞檢測呢？

假設有這樣一個系統，可以在用戶與系統之前獲取到所有的請求，并分發給掃描器進行檢測，這樣只要請求來自于真實的應用場景或者系統的功能，那么就可以最大程度地收集到所有真實有效的資源。故可以設計該系統包含如下的子模塊：

客戶端：用戶訪問系統的載體，如：瀏覽器，手機APP

代理：用于獲取來自于客戶端的所有請求，如：Burp，Load Balancer

解析器：負責將代理獲取的請求數據按照規定格式解析并插入至請求數據庫中

請求數據庫：用于存放代理獲取的所有請求數據以及解析器和掃描器的配置信息

掃描器：具有漏洞檢測功能的掃描器，如：自行編寫的定制掃描器(hackUtils)，SQLMAP，Burp Scanner，WVS，OWASP ZAP等

應用系統：目標應用系統，如：Web系統，APP

基本架構如下：

從上圖中，代理可以將所有對目標系統的訪問請求獲取并存儲在一個中心數據庫中，然后將這些真實的請求分發給不同的掃描器進行檢測。每個子模塊都只負責自己的功能，相互之間并不干擾，且僅通過中心數據庫關聯起來，因此可以靈活擴展多個代理和掃描器。例如：

• 對于測試人員，只需要在本地設置好代理(如：burp)，然后在瀏覽器或者APP中正常地訪問或者測試應用的每一個頁面和功能，接下來的漏洞檢測工作就完全交給了掃描器去做，這極大地節約了時間和避免了大量重復的手工檢測的工作。

• 對于企業系統，可以將代理設置在應用前端(如：load balancer)，這樣所有的請求將會被自動鏡像在掃描數據庫，并自動分發給多個掃描引擎進行檢測，無需手工干預即可發現很多隱藏很深的漏洞。

實踐

為驗證這種思路，筆者設計了一個Demo。

該系統在瀏覽器或者手機的wifi中配置好了burp作為代理，瀏覽應用的每一個頁面和功能時，代理將會自動地收集所有請求數據，包括各種請求頭、cookie、請求方法、請求數據等，然后通過解析器的解析并存儲于中央數據庫，最后再分發于多個掃描引擎對請求的所有可控輸入點進行repeat檢測。效果如下：

以下是我封裝的一個python的requests庫，它支持發送自定義的cookie，headers的get/post的請求，并可以是使用PhantomJS引擎去解析和渲染GET請求響應的頁面中的javascript，css等，可以非常方便的應用于反爬蟲和DOM型XSS的檢測。Code：

https://github.com/brianwrf/HackRequests

思考

從漏洞檢測的角度來說，經過筆者的測試(以DVWA和WebGoat為例)檢測效果還是非常明顯和有效的。其實這種類似的設計，很早之前就已經有人做了，那么很多人要問了為什么你還要在重復造個輪子呢？其實原因有以下幾點：

1.系統耦合性較強，不利于進行擴展和改造

2.在HTTPS的流量捕獲上支持的不是很好

3.沒有做到對HTTP請求中所有的可控輸入點進行檢測，例如，僅僅檢測GET/POST數據，而對cookie，user-agent, referer等缺乏檢測

4.缺乏對于DOM的渲染和解析，容易造成對于基于DOM的漏洞的漏報，比如：DOM型的XSS等

5.不具備分布式部署的能力，無法有效利用分布式處理的優點來提高檢測效率

6.不具備真正的意義上的repeat檢測能力，換句話說不能完全模擬用戶的請求

當然，上述的設計也存在一些待解決的問題，比如：若將代理部署至應用前端鏡像所有請求，再分發至掃描引擎檢測，如何防止真實用戶數據泄漏和篡改？可能的解決方案是設置例外，對于敏感字段或者請求進行例外處理。

總結

以上是生活随笔為你收集整理的web漏洞扫描器原理_面向WEB的分布式漏洞扫描器的设计与实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。