WAF防護能力評測及工具

本篇文章介紹如何從常規攻擊的防護能力來評測一款WAF。一共覆蓋了十六種攻擊類型，每種類型均從利用場景（攻擊操做的目的），注入點（漏洞產生的地方，好比說大多數WAF都會較全面地覆蓋來自GET請求的攻擊，有選擇地覆蓋來自POST請求的攻擊而忽略來自請求頭的攻擊）和繞過方式來評測，最後附上評測代碼。

 

1、SQL注入（注入）

 

1. 利用場景

從攻擊者進行SQL注入的階段來看，通常分爲探測與攻擊兩個階段（p.s.攻擊階段是WAF的重點防護階段）

（1）探測階段

1)     探測是否存在SQL注入：基於 SQL錯誤回顯(e.g.extractvalue ) 或 時間響應(Benchmark,sleep )來探測目標網站是否存在SQL注入點

2)     識別數據庫類型：根據數據庫的slang來判斷目標網站採用的哪一種數據庫及數據庫的版本等基本信息，例如@@version,user()

（2）利用階段

i. select型SQLi

1)     讀取元數據庫：經過讀取數據庫管理系統元數據庫（e.g. MySQL的information_schema, SQL Server的sysobjects）來探測數據存儲數據庫，表，列等基本信息
2)     提取數據：使用union查詢或盲注中的逐位探測(e.g. length,substr)或者條件探測(Select if(1=1,’a’,’b’);)來提取數據庫管理系統中的數據，其中常常會用到concat(),group_concat()等函數,

3)     讀取系統文件：讀取數據庫管理系統所在操做系統中的重要系統文件(eg. MySQL的load_file)
4)     寫入系統文件：向數據庫管理系統所在操做系統寫入後門文件(e.g.MySQL的select into outfile)
5)     執行系統命令：以數據庫管理系統爲跳板執行系統命令(e.g.SQL Server的exec master…xp_cmdshell)

ii. update型SQLi

iii. insert型SQLi

 

2.注入點

記住：任何輸入都是有害的

（1）GET QueryString 
（2）POST
（3）Referer
（4）Cookie
（5）X_Forwarded_For
（6）UserAgent
（7）Basic-Authorization

 

特別注意：注入點不只僅只存在於參數值，也存在於參數名，url路徑，那種只檢測參數值的WAF的防護能力一定有限

 

3.繞過方式

這裏的繞過主要是針對採起模式匹配來識別攻擊的WAF檢測方法（其實大多數WAF的基本方法都是這個，引伸到IDS,IPS,anti-virus等安全產品都是採起的這種方法）

 

採起模式匹配的檢測方法會繞過的緣由無外乎如下幾種：

1）HTTP協議解析漏洞 ：WAF進行模式匹配的時候都是對HTTP協議變量進行匹配，攻擊者構造異常的HTTP數據包致使不能正常提取變量，都不能進入到模式匹配階段，天然而然就繞過了

 

2）模式匹配的先天不良：字符串匹配，不管是簡單的正則匹配或者會配合必定的邏輯的匹配（好比對不一樣關鍵字進行加權操做，先後依賴關係判斷）反正都逃不開模式兩個字，而模式是固定的，就致使了各類側漏。 

 

對 於第二點，在雲WAF上的問題最爲嚴重，咱們知道雲WAF的用戶類型是多樣化的（不一樣的搭建技術PHP/ASP/JSP，運行環境Windows /Linux，訪問方式PC/Mobile），理想狀態下，應該按站點類型精準投放防護規則，可是..基於站點自動建模（安全人員中缺少數據分析師）是個 「前沿」的技術活，而免費模式下是產生不了多大動力來投入精力的，因此現實是傾向於選擇更通用的方式（放棄少數人）按危害優先級來定製規則。

 

以上繞過緣由衍生了如下的通用繞過方式

（1）參數污染

（2）URL重寫 

http://localhost/uyg/id/123+or+1=1/tp/456

（3) 加密payload

MD五、SHA-一、自定義加密

（4）緩衝區溢出

（5）編碼繞過 

（6）特殊字符插入（％00）

（7）異常HTTP請求包（e.g.超級大，不符合HTTP規範但被server容錯的數據包）

（8）數據包分塊傳輸方式Transfer-Encoding: chunked

 

SQL注入通常存在如下繞過方式（其實也就是模式匹配的先天不良）

1) 編碼繞過：經過對SQL注入攻擊Payload進行Unicode編碼，十六進制編碼，雙URL編碼來繞過檢測規則
2) 註釋語句繞過：經過在SQL注入攻擊Payload中插入註釋語句（內聯註釋)來繞過檢測規則
3)大小寫繞過：經過變化SQL注入攻擊Payload的大小寫來繞過檢測規則
4) 類型轉換繞過：使用hex, ascii, ord, char，chr，cast，convert等類型轉換函數來變化特定字符來繞過檢測規則，除了類型轉換函數還有隱性類型轉換的特徵  http://danqingdani.blog.163.com/blog/static/186094195201331854938182/

5) 生僻的SQL關鍵字繞過

6)特殊的sql語法（e.g. mysql . ~ ! + - 符號）

7)關鍵字拆分

8)請求方式轉換（將GET轉變爲POST，由於誤報的問題POST的規則要遠遠比GET規則鬆）

（參考了Seay大神總結的繞過方式）

 

2、文件包含（文件操做）

攻擊的核心目標之一是信息操縱，而信息的載體就是文件（數據），對文件的非法讀、寫、刪除等操做就成爲防護的核心。

 

1.利用場景

（1）包含本地文件

本地文件包含的出發點通常分爲兩種

 

a. 讀取系統文件獲取敏感信息，例如配置文件

除了讀取同目錄下的文件外，通常會配合目錄遍歷

 

b. 實施代碼執行

（1）包含（執行）存在後門的文件（寫入後門的方法有不少，例如SQLI寫馬/文件上傳寫馬/代碼注入）

（2）包含（執行）系統可執行文件

（2）使用php://input 協議將文件包含漏洞變成代碼執行漏洞  http://danqingdani.blog.163.com/blog/static/1860941952013993810261/

（2）包含遠程文件

 

2.注入點

記住：任何輸入都是有害的

（1）GET QueryString 
（2）POST

 

3.繞過方式

繞過目錄遍歷檢測（其實目錄遍歷因該單獨列出來，在命令執行等地方都會用到）

1) 編碼繞過：

b. %c0%af Apache，Tomcat UTF-8編碼錯誤
c. %25%5c Unicode漏洞
d. %c0%af 

e. %c1%9c Unicode漏洞

f. %fc%80%80%80%80%af Unicode漏洞

2) 截斷: %00

 

讀取系統文件時的繞過檢測方法

1) 使用php://filter協議以base64編碼方式讀取指定文件內容

2)使用data:// URI schema協議執行系統命令

 

3、文件上傳/下載（文件操做）

 

1.利用場景

（1）直接上傳webshell文件

通常的文件上傳模塊，都會配置文件上傳白名單（e.g.只容許上傳圖片文件) ，因此這種攻擊方式的通常看是否有白名單以及如何繞過白名單

 

webshell的類型以下：

1> asp shell

2> php shell

3> jsp shell

4> python shell

5> pl-cgi shell

6> sh shell

7> c shell

8> cfm shell

9> exe shell

 

 

（2）圖片寫立刻傳

在文件名沒法作文章的狀況下，通常會配合 服務器解析漏洞或者文件包含漏洞來利用

 

（3）下載任意文件

處理用戶請求的時候容許用戶提交文件路徑，攻擊者經過變化目錄或文件地址來達到下載系統敏感文件的目的

 

補充: 

(1) PUT HTTP Method

(2) ActiveX

(3)JavaApplets

2.注入點

文件上傳表單 

 

3.繞過

文件名白名單繞過

（1）利用上傳文件請求的解析漏洞，e.g.不能正常提取文件名

（2）配合服務器解析漏洞，構造奇怪的文件名繞過白名單, e.g. file.php%00.jpg

 

服務器解析漏洞

（1）Apache解析漏洞

xxx.php.jpg

xxx.php.rar

xxx.php.x1.x2.x3

xxx.php. (windows下點和空格都會被自動消除）

 

（2）Nginx解析漏洞

xxx.jpg%00.php

xxx.jpg/a.php

 

（3）IIS解析漏洞

xxx.asp;.jpg xxx.asa;.jpg xxx.cer;.jpg xxx.cdx;.jpg

xxx.asp:.jpg xxx.asa:.jpg xxx.cer:.jpg xxx.cdx:.jpg

xxx.asp/xx.jpg xxx.asa/xx.jpg xxx.cer/xx.jpg xxx.cdx/xx.jpg

 

參考  http://drops.wooyun.org/papers/539

 

4、命令執行 （注入）

 

1.利用場景

輸入點接收並運行系統命令

 

2.注入點

（1）POST

（2）GET

（3）Cookie

5、代碼執行 （注入）

 

1.利用場景

（1）輸入點接收並運行PHP/JSP/ASP代碼

 

2.注入點

（1）POST

（2）GET

（3）Cookie

 

 

6、webshell (這個分類有點糾結，主要是從已經被種馬的狀況下看可否攔截）

1.利用場景

配合文件上傳、代碼執行，SQLI寫馬等操做寫入webshell後進行webshell鏈接

 

webshell按傳遞payload來分類的

（1）payload採用請求頭提交，以cookie提交最多，其中採起自定義請求頭更隱蔽

（2）payload採用POST提交

 

2.注入點

（1）GET QueryString 
（2）POST

（3）Cookie

（4）其餘請求頭

 

3.繞過方式

webshell payload提交的時候通常都會加密

 

如下列出常見的webshell，能夠探測一下這些基本的webshell WAF是否能攔截

caidao一句話鏈接客戶端

Lanker微型php 後門客戶 2.0正式版 一句話鏈接客戶端

weevely php後門生成工具及客戶端端

webacco php後門生成工具及客戶端端

phpspy.php

b374k.php

80sec.php

90sec.php

r57.php

c99.php

b4che10r

X14ob-Sh3ll

aspxspy

server_sync.php (phpadmin後門文件）

 

7、XSS

1. 利用場景

從攻擊者進行  XSS 注的階段來看，通常分爲探測與攻擊兩個階段。

探測階段是指彈框測試  xss 是否存在，經常使用 alert(),prompt(),confirm() 等函數（彈框只是一種，也有看  html 標籤是否能實際運行）；

攻擊階段是指在確認存在  XSS 後，進行利用，例如盲打盜取  cookie(session hijacking)僞造用戶身份登錄 ，蠕蟲傳播， keylogger,下載安裝惡意軟件，構造釣魚頁面

（xss我瞭解的太少，xss好複雜滴說，按成因劃分有反射型xss，存儲型xss，DOM型XSS，mXSS（突變型XSS），UXSS（通用型XSS），按平臺劃分還有flash xss，xss和sqli的攻擊方式都能出成一本書了）

 

2.注入點

記住：任何輸入都是有害的

（1）GET QueryString 
（2）POST
（3）Cookie

3.繞過方式

1）編碼繞過（url unicode編碼，base64編碼）
2）使用Data URI schema繞過
3）使用Javascript僞協議
4）基於事件函數繞過
5）類型轉換繞過引號e.g.String.fromCharCode

6）xss payload在錨點後提交   https://www.securusglobal.com/community/2014/10/13/bypassing-wafs-with-svg/

 

 

8、CSRF

（其實CSRF更像一種攻擊模式而不只僅是漏洞類型）

1.攻擊場景

因爲http請求無狀態，而服務器僅僅依賴於用戶瀏覽器發送cookie信息進行身份合法性判斷，而web瀏覽器會自動發送session id（cookie）的特性，攻擊者誘使受害者訪問惡意請求，以受害者的身份執行「構造」的請求 

 

2.注入點

記住：任何輸入都是有害的

（1）GET QueryString 
（2）POST

 

3.繞過方式

csrf其實是一種邏輯上的錯誤，常規csrf的防護其實就很差辦（不能根據referer，有些csrf結合xss原本請求就是本域發起；並且還存在協議轉換丟referer，mobile平臺丟referer的狀況）

 

九 、自動化工具攻擊

自動化工具的攻擊據統計佔了總攻擊的90%，可否準確的攔截這些自動化工具是很是考驗WAF能力的評測項。

自動化工具分爲離線工具與在線工具

 

<1>在線工具（基本是綜合性工具）：

各類CDN服務都附帶網絡安全在線檢測功能（雲端掃描器），這裏就不說起了

 

<2>離線工具分爲如下幾類：

a. 漏洞掃描器

 

（1）綜合漏洞掃描器

這裏列出比較經常使用的

scanner信息參考  http://www.sectoolmarket.com/price-and-feature-comparison-of-web-application-scanners-unified-list.html

AWVS
AppScan
WebInspect
NetSparker
Websecurify
WebCruiser
Nikto
wikto 
w3af
vega
OWASP-ZAP
arachni-scanner
golismero 
brakeman ruby on rails漏洞掃描器
grendel-scan 

 

（2）專項掃描器

a. SQLI/NoSQLI

Havij, SQLMap, Pangolin

 

b.XSS

X5S，XSScrapy

 

c.文件包含

fimap

 

d.開源框架漏洞掃描器 

wpscan

joomscan

 

（3）密碼破解工具

hydra

medusa

patator

 

（4）目錄字典攻擊工具

Pker

dirbuster

 

（5）其餘

burpsuit

MSF

 

還有各類本身寫的腳本工具 sh/perl/python(e.g. pycurl,python-urllib)/php/ruby/java

 

10、惡意爬蟲/採集器/機器人 

惡意爬蟲／採集器／機器人會給之內容爲王，帶寬又不寬裕的小網站帶來要命的傷害，因此也是評測WAF防護能力的重要方面，可否有效精準地 將其與搜索引擎（搜索引擎是不會提供其完整的IP段的）與正常的API調用區分開來一直是WAF面臨的難題。

1.攻擊場景

（1）假裝成搜索引擎繞過檢測，該場景適用於缺乏準確的的搜索引擎判斷方法

（2）自動發送垃圾評論機器人等

 

 

11、信息泄露

1.攻擊場景

(1) 系統文件

直接訪問備份、隱藏等信息文件

(2) 錯誤回顯

暴目錄，暴路徑

(3)列目錄

(4)管理後臺暴露：搜索引擎收錄管理後臺後如何處理

 

十二 、重定向

主要用於釣魚

通常狀況下WAF是不會防護這種漏洞

 

十3、基於會話的攻擊

1.攻擊場景

（1）採用固定的會話

（2）會話ID生成算法可猜想

（3）利用xss等其餘漏洞劫持會話ID

 

十4、權限驗證漏洞

1.攻擊場景

垂直/水平提高權限

（1）請求參數來控制權限

（2）referer來控制訪問權限

通常狀況下WAF不會防護這種漏洞（基本邏輯漏洞雲WAF都不會防護）

 

十五 、拒絕服務

1.攻擊場景

（1）xml billion laughs （消耗內存）

（2）CC （消耗帶寬）

（3）slow HTTP DoS （消耗帶寬）

 

 

十6、其餘漏洞

（1）HTTP響應拆分

（2）XML實體攻擊 能夠參考pnig0s大牛的《XML實體攻擊－從內網探測到命令執行步步驚心》 

（3）隱藏參數篡改

     1）hidden表單值篡改

     2）viewstate值篡改 

 （4）其餘注入

     1）XXE注入

     2)  XPath注入

     3）LDAP注入

     4）CRLF注入

 （5）邏輯錯誤  雲WAF不會防！！

 

上訴評測的方法都是從WAF防護覆蓋度來考慮的，覆蓋的越全固然越好。

 

其實，WAF防護能力的評測歸納的說就是檢出率 （漏報率 false negative）與準確率 （誤報率false 

positive）。檢出率是通常是WAF廠商對外宣傳的核心，而實際準確率（很多雲WAF對管理後臺，API接口調用，富文

 

本的誤報就滿嚴重的）更爲重要（安全必定不能影響正常使用），後續另開一篇來說誤報的問題。

 

十7、WAF測試工具

 

WAF能力評測的方法，一句話來講，就是構造攻擊場景，發送攻擊包，看WAF的響應。

 

測試工具地址： https://github.com/tanjiti/WAFTest 

 

源碼介紹：

（1）攻擊場景

https://github.com/tanjiti/WAFTest/tree/master/vulCode （持續添加中）

（2）發包工具

https://github.com/tanjiti/WAFTest/blob/master/HTTP.pl （參考： HTTP.pl——經過HTTP發包工具瞭解HTTP協議 ）

https://github.com/tanjiti/WAFTest/blob/master/HTTPFromFile.pl （從文件讀取HTTP包內容，併發送）

（3）攻擊包

https://github.com/tanjiti/WAFTest/tree/master/t   （持續添加中）

 

測試示例：

git clone https://github.com/tanjiti/WAFTest.git

perl HTTPFromFile.pl -host www.tanjiti.com -dir t -code 403

 

選項說明以下

perl HTTPFromFile.pl --help

 

Usage: perl HTTPFromFile.pl [-code 403] [-uri 127.0.0.1] [-host example.com] [-port 80] -file request_file_path

 

 

-code: 指定攔截響應碼，默認爲403，不一樣的WAF會爲攔截響應定製不一樣的響應碼

 

-uri: 指定使用WAF的IP或域名,默認127.0.0.1

 

-host: 指定發送請求的Host頭，若是uri未指定，則uri設置爲host的值，默認localhost

 

-port: 指定使用WAF的端口號，默認80

 

-file: T文件的文件路徑

 

-dir: 存放T文件的目錄路徑