搜索公眾號：暗網黑客
可領全套網絡安全課程、配套攻防靶場
不知不覺來到掌控學院也快兩個月了，想起倆個月前，從零開始，一步一個腳印的走到現在。雖然有時很疲憊，但是卻很快樂。
在下才疏學淺，僅在這裡發表一下不成熟的見解
希望對大家的提升有所幫助首先我們要了解什麼是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上 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
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和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://ocalhost/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://ocalhostest/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的防護不會對其進行攔截//變量$a的值我是利用異或賦值的，$a = “~+d()”^”!{+{}”;，而字符串”~+d()”^”!{+{}”異或的結果為_POST,然後$b = ${$a}[a];與$b = $_POST[a]等價
在將其傳入eval()中但是單純的一句話木馬：是絕對不可能在對方電腦上正常執行的 所以我們還是要不斷與時俱進的
文筆拙劣 各位見諒哦~
點擊下方直接跳轉至上述視頻教程頁面
免費觀看更多黑客滲透實戰視頻
作者來自Track安全社區：aj545302905
