Web掃描器通過構造特殊請求的方式，對Web系統可能存在的安全漏洞進行掃描，是滲透工作的必備工具。本文嘗試從掃描器檢測方向出發，根據掃描器的功能和所產生的請求內容對其進行分類，結合蘇寧Web應用防火墻(WAF)日志數據，分別展示了規則模型、統計特征模型和基于n-gram的的MLP模型在Web掃描器識別上的簡單實踐效果，供大家參考。

一. 掃描器概覽

圖1 - 掃描器分類

1 敏感內容掃描

俗話說知己知彼方能百戰不殆，當黑客或滲透測試人員面對一個未知站點時，這個站點對他們來說就是一個黑盒。這時候不妨拿敏感內容掃描器先給它來個一把嗦摸摸底，指不定就能掃到有價值信息，找到撬動安全防護缺口的第一把鑰匙。

敏感內容掃描器通常具備一系列敏感路徑及敏感文件的字典，掃描器利用這些敏感內容字典對站點進行盲掃來判斷是否存在這些敏感內容；進一步地，通過響應數據包對站點目錄結構及其他信息進行判斷，為下一步針對性單點突破作準備。

這里提到了一個字典的概念，字典這玩意很重要，可以說字典的質量、廣度和深度決定了這個掃描器的上限。相對于IP代理、UA偽造、隨機化訪問時間間隔這些偽裝手段來說，敏感內容是固定的，翻來覆去就這么多東西，同時因為請求資源不存在大多數會返回404狀態碼(有些會觸發WAF攔截策略返回403，還有些因為服務器設置了默認跳轉狀態碼為301或302)。攻方選手通常不會構造毫無意義的字典內容來浪費有限的資源和精力，這些字典通常包含如下內容信息(忽略大小寫)：

? 敏感目錄信息：如/admin/, /phpadmin/, /mysqladmin/, /usr/local/, /etc/passwd/, ...

? 敏感配置文件：如.bashrc, .bash_history, conf.icn, config.inc, ...

? 版本文件信息：如/.git/config, /.svn/entries, /.bzr/xxx, ...

? 備份文件信息：如bak, index.php.bak, database.wsp, backup.zip, ...

? 密鑰文件信息：如/.ssh/idrsa, /.ssh/knownhosts, idrsa.pub, authorizedkeys, ...

? 日志文件信息：如/logs/error.log, /logs/auth.log, /var/log/mysql/mysql.log, ...

? 其他敏感文件：如php, system.inc, mysql.inc, shell.php, ...

2 Web漏洞掃描

漏洞掃描器通常會與爬蟲相結合。首先利用爬蟲獲取到頁面可能存在注入點的接口，然后針對該接口來一個SQl注入、XSS注入、命令注入一把嗦，對于一些安全防護意識低的站點往往能取到最直接的效果。針對這類掃描請求，WAF都能夠做到單點正則過濾，理論上會攔截返回大量403狀態碼，但是掃描器常針對一些新域名或偏僻的域名進行掃描，這些域名往往沒有啟用WAF攻擊防護，因此實際上是有很多是未被攔截的非403狀態碼。同上述敏感內容掃描，這類請求往往也具備明顯的文本特征，下面分別以SQL注入、文件包含和XSS跨站掃描舉例。

2.1 sql注入漏洞掃描

SQL注入攻擊是一種注入攻擊，它將SQL命令注入到數據層輸入，從而影響執行預定義的SQL命令；通過控制部分SQL語句，攻擊者可以查詢數據庫中任何自己需要的數據，利用數據庫的一些特性，可以直接獲取數據庫服務器的系統權限。

首先，判斷接口是否存在注入點，如：

? 若參數ID為數字，加減運算判斷是否存在數字型注入；

? 參數后加單雙引號，判斷返回結果是否報錯；

? 添加注釋符判斷前后是否有報錯：如id=1' --+ 或 id=1" --+或id=1' #或id=1" --+；

? 有些參數可能在括號里面，所以也可以在參數后面加單雙引號和括號，如id=1') --+或 id=1") --+或id=1') #或id=1") --+；

? 參數后面跟or 或者and，判斷返回結果是否有變化，如1' or 'a'='a或者and 'a'='a或者1' or 'a'='b或者1' or '1'='2；

? 也可以考慮時間延遲的方法判斷是否存在注入，如 1’ and sleep(5)。

然后對存在注入漏洞的點利用聯合查詢一步步獲取信息，如：

? 查詢數據庫名：id=0' union select NULL,database(),NULL --+ ；

? 爆庫名：id=0' union select null,groupconcat(schemaname),null from information_schema.schemata --+；

? 報表名：id=0' union select null,groupconcat(tablename),null from informationtables where tableschema='security' --+；

? 爆字段名：id=0' union select null,groupconcat(columnname),null from informationcolumns where tableschema='security' and table_name='users' --+；

或者通過報錯回顯查詢結果，如：

? 回顯數據庫名：and extractvalue(1,concat(0x7e,(select database())))；

? 回顯表名：
and extractvalue(1,concat(0x7e,(select groupconcat(tablename) from informationtables where tableschema='security' ))) ；

? 回顯列名：
and extractvalue(1,concat(0x7e,(select groupconcat(columnname) from informationcolumns where tableschema='security' and table_name='users')))。

2.2 文件包含漏洞掃描

服務器通過PHP的特性(函數)去包含任意文件時，由于要包含的這個文件來源過濾不嚴，從而可以去包含一個惡意文件，非法用戶可以構造這個惡意文件來達到惡意的目的，如讀取目標主機上的其他文件，遠程文件包含可運行的PHP木馬，包含一個創建文件的PHP文件，本地文件包含等。

? Include:包含并運行指定文件，當包含外部文件發生錯誤時，系統給出警告，但整個php文件繼續執行；

? Require:跟include唯一不同的是，當產生錯誤時候，include下面繼續運行而require停止運行了；

? Include_once:這個函數跟include函數作用幾乎相同，只是他在導入函數之前先檢測下該文件是否被導入，如果已經執行一遍那么就不重復執行了；

? Requireonce:這個函數跟require的區別 跟上面所講的include和includeonce一樣。

2.3 XSS跨站漏洞

跨站腳本攻擊是指惡意攻擊者往Web頁面里插入惡意Script代碼，當用戶瀏覽該網頁時，嵌入網頁中的Script代碼會被執行，從而達到惡意攻擊用戶的目的。與正常請求相比，XSS請求也具備明顯的文本特征，如alert(0),等。

二. 規則模型

掃描器檢測與Web攻擊檢測不同之處在于，掃描是一種持續的行為，我們通過對掃描器持續一段時間的請求進行聚合分析，而Web攻擊檢測則是把每條請求作為一次獨立的事件來判斷是否為Web攻擊。掃描器在請求不存在的資源時往往會返回狀態碼404，但實際生產環境中并非如此。尤其是作為電商企業，希望被正面的搜索引擎抓取，返回404的這種方式會對SEO搜索引擎優化產生不利影響，因此多數域名針對這種請求會做3XX的跳轉。總體來說，大量返回404的請求往往都是盲掃請求，但仍有大量盲掃請求返回狀態碼并非404。這里依賴Web請求日志，在一定時間被僅對請求url文本特征進行分析，來識別掃描器。

1 正則提取

敏感內容掃描器往往會請求敏感路徑、敏感文件等信息，因此首先收集這些信息，然后用正則去匹配這些內容。這里分別按照敏感信息的類型進行分類：

2 正則優化

正則順序優化：按照Sensitive類的定義，當url匹配到關鍵內容后即返回匹配內容，跳出正則過濾的循環。因此，為了進一步降低性能的消耗，將生產環境中命中頻率最高的正則放在最前面，命中率低的正則放在靠后位置。

單條正則調優：由于正則匹配搜索的優先級為由左向右，因此將生產環境中命中頻率最高的放在左邊，最低的放在最右邊。

3 準確率和召回率評估

評估方式：模型部署在準實時分布式計算平臺，按每分鐘進行聚合，并將檢測到的掃描器數據作為Log日志打印。根據Yarn日志輸出的掃描器IP和檢測到的請求時間在云跡進行抽樣驗證。

三. 統計特征ML模型

掃描器請求和正常請求之間除了文本特征以外，在狀態碼、url長度、所攜帶ua的混亂度及訪問域名的混亂度等也存在一定差異性。因此提取命中關鍵詞次數及上述特征，結合WAF正常日志和規則檢測到的掃描器日志形成黑白樣本，進一步訓練ML模型。

1 特征提取

關鍵詞提取:搜集網上常見的集中掃描器提取敏感內容字典，并結合規則模型識別的掃描器日志加以補充。進一步隨機提取全網流量作為白樣本對掃描器關鍵詞庫進行匹配，并將白樣本中大量存在的關鍵詞剔除，組成關鍵詞庫。

2 特征工程

除了關鍵詞系數特征，同時還分別提取了請求次數、敏感詞個數、敏感詞威脅系數、UA混亂度、域名混亂度、狀態碼等特征占比進行示范。

3 模型評估

對規則模型采集的黑樣本及Web日志白樣本進行逐個人為驗證并打標，進而訓練隨機森林模型、和MLP模型分別用召回率、準確率和F1得分進行評估。模型在訓練及表現良好，但測試集中可以看出模型過擬合驗證，結構風險太高。無法滿足生產環境真實業務場景需求。針對不同的模型通過降低樹深度、前后剪枝，調整懲罰系數等方式降低模型結構風險造成準確率和召回率降低，左右權衡后效果均未能達到滿意效果。

? 隨機森林模型評估：

? MLP**模型評估**

四. 基于n-gram特征提取的MLP模型

1 模型訓練示范

對傳統機器學習來說，特征提取是比較繁瑣的，需要對業務場景的深入理解。在掃描器識別任務中，我們可以將單個用戶連續發起的請求序列拼接到一起作為一個短文本，采取NLP中情感分析的思想，分別訓練詞向量和分類器模型對掃描器請求序列進行識別。訓練過程中需要注意參數n-gram和maxfeatures的調整，這里分別代表取詞方式和特征維度。我們先取部分數據實驗不同的n-gram參數和maxfeatures參數進行模型訓練，并對測試集數據進行評估。在保證模型測試及評分的基礎上，max_features越小資源消耗越小。

2 模型評估示范

我們從蘇寧應用防火墻(SNWAF)日志中抽取了拼接275019條正常訪問序列作為正樣本，同時通過SNWAF輸出的掃描器IP列表提取拼接出361504條掃描器IP的訪問序列作為黑樣本，對模型進行訓練，取得了比規則模型和統計特征ML模型更好的效果。該方法有更好的成長性，可以隨著高質量訓練數據的增長進行優化迭代，同時缺點是模型結構相比前兩者略復雜，資源消耗也較大。

我們分別針對不同的maxfeatures進行了k-flod測試，當maxfeatures=1500時取得了較好的模型表現，交叉驗證集平均曲線下面積(AUC)約為0.99。

3 模型工程化部署

實際工程化應用時，我們要將模型部署到分布式大數據計算平臺。在實際的代碼工程化部署過程中，可能會出現訓練模型的環境與分布式環境模塊版本不一致或缺少模塊導致的模型加載失敗問題。針對上述問題，我們采取了一些辦法：

抽取countvectorizer模型的字典向量，手動構建詞向量轉換函數

重寫MLP模型預測代碼，將模型預測邏輯函數化

通過本地測試我們發現，采取上述方式與加載模型的輸出結果一致，并且預測效率更高。

我們通過創建pyspark-streaming任務，實時消費WAF訪問日志對每批次用戶的訪問日志進行向量化轉化后輸入預測模型，從而實現掃描器的實時監控，并將檢測到的掃描器IP進行告警或根據配置實施訪問限制。

五. 總結

本文對各類web掃描器特征進行了梳理和總結，并展示了利用規則模型和統計特征ML模型對掃描器的識別效果。

其中規則模型有天然的優勢，所見即所得，可信度高可解釋性強，同時滿足奧卡姆剃刀簡單高效原則，然而只對已知的掃描類型有效，合理的閾值設計非常重要，需要結合實際業務流量來精準分析；基于統計特征的機器學習識別模型的特征提取相對簡單，只抽取了少量數據集進行訓練，表達能力有限，不能夠充分學習到正常請求行為和掃描器行為的區別，有興趣的同學可以在此基礎上進行更加精細化的特征提取以達到識別率的提升；基于n-gram特征提取的機器學習模型具備更好的成長性，可以隨著高質量訓練樣本數據的增加進行優化迭代，同時缺點是相對前兩種方式資源消耗較大。

在實際的生產應用中，我們選擇AI模型的落地，需要根據企業的數據規模、資源情況和需求標準來選擇適合自己場景的模型和方式，最適合的才是最好的。

由于本人能力有限，如有不足之處還望指正，看官若有其他新穎檢測思路歡迎一起交流，互通有無。

總結

以上是生活随笔為你收集整理的web漏洞扫描器原理_黑客秘籍：基于WAF日志的扫描器检测实践的全部內容，希望文章能夠幫你解決所遇到的問題。

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