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

一、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.注入點

記?。喝魏屋斎攵际怯泻Φ?/p>

(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

MD5、SHA-1、自定義加密

(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大神總結的繞過方式)

二、文件包含(文件操作)

攻擊的核心目標之一是信息操縱，而信息的載體就是文件(數據)，對文件的非法讀、寫、刪除等操作就成為防御的核心。

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協議執行系統命令

三、文件上傳/下載(文件操作)

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

四、命令執行 (注入)

1.利用場景

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

2.注入點

(1)POST

(2)GET

(3)Cookie

五、代碼執行 (注入)

1.利用場景

(1)輸入點接收并運行PHP/JSP/ASP代碼

2.注入點

(1)POST

(2)GET

(3)Cookie

六、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后門文件)

七、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/

八、CSRF

(其實CSRF更像一種攻擊模式而不僅僅是漏洞類型)

1.攻擊場景

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

2.注入點

記?。喝魏屋斎攵际怯泻Φ?/p>

(1)GET QueryString

(2)POST

3.繞過方式

csrf實際上是一種邏輯上的錯誤，常規csrf的防御其實就不好辦(不能根據referer，有些csrf結合xss本來請求就是本域發起;而且還存在協議轉換丟referer，mobile平臺丟referer的情況)

九 、自動化工具攻擊

自動化工具的攻擊據統計占了總攻擊的90%，能否準確的攔截這些自動化工具是非?？简濿AF能力的評測項。

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

<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

十、惡意爬蟲/采集器/機器人

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

1.攻擊場景

(1)偽裝成搜索引擎繞過檢測，該場景適用于缺少準確的的搜索引擎判斷方法

(2)自動發送垃圾評論機器人等

十一、信息泄露

1.攻擊場景

(1) 系統文件

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

(2) 錯誤回顯

暴目錄，暴路徑

(3)列目錄

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

十二 、重定向

主要用于釣魚

一般情況下WAF是不會防御這種漏洞

十三、基于會話的攻擊

1.攻擊場景

(1)采用固定的會話

(2)會話ID生成算法可猜測

(3)利用xss等其他漏洞劫持會話ID

十四、權限驗證漏洞

1.攻擊場景

垂直/水平提升權限

(1)請求參數來控制權限

(2)referer來控制訪問權限

一般情況下WAF不會防御這種漏洞(基本邏輯漏洞云WAF都不會防御)

十五 、拒絕服務

1.攻擊場景

(1)xml billion laughs (消耗內存)

(2)CC (消耗帶寬)

(3)slow HTTP DoS(消耗帶寬)

十六、其他漏洞

(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接口調用，富文

本的誤報就滿嚴重的)更為重要(安全一定不能影響正常使用)，后續另開一篇來講誤報的問題。

十七、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 --helpUsage: 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文件的目錄路徑。

原文地址：http://danqingdani.blog.163.com/blog/static/1860941952014101462723470/