0x01 CDN WAF繞過#

 

CDN的全稱是Content Delivery Network，即內容分發網絡。其基本思路是盡可能避開互聯網上有可能影響數據傳輸速度和穩定性的瓶頸和環節，使內容傳輸的更快、更穩定。通過在網絡各處放置節點服務器所構成的在現有的互聯網基礎之上的一層智能虛擬網絡，CDN系統能夠實時地根據網絡流量和各節點的連接、負載狀況以及到用戶的距離和響應時間等綜合信息將用戶的請求重新導向離用戶最近的服務節點上。其目的是使用戶可就近取得所需內容，解決 Internet網絡擁擠的狀況，提高用戶訪問網站的響應速度。 --來源“百度”

 

目前CDN服務的功能是越來越多，安全性也越加強悍，用戶的每個請求都會被發送到指定的CDN節點上，最后轉發給真實站點。這個過程就好像加了一道關卡，這個關卡提供了緩存、加速、防御的特點。

 

在滲透測試中，如果遇到了CDN站點，幾乎許多測試請求都會被CDN攔截，甚至多次請求后，會被加入黑名單。這個CDN節點屬于云端WAF，如果將數據直接發送給真實站點，那么也就沒有CDN的處理了，整個防御就沒有任何作用。

 

那么下面我來帶給大家幾個方法來繞過云端WAF。首先我們必須要查詢到目標站點的真實地址才可以，這里的真實地址就指的是真實IP。以下幾個方法只是個人之見，如果有遺漏或者缺點，請在文章評論指出……

 

第一個，查詢域名歷史DNS解析，網上有很多站點都可以查詢站點的歷史DNS解析。假設我在本月10號，域名綁定的服務器IP是199.199.199.，在下月15號更換了服務器的IP，那么這個199.199.199.可能就會被直接記錄在歷史記錄中。再根據歷史記錄進行判斷當前IP是否是現在的網站真實服務器地址。

 

 

 

第二個，查看子域名解析地址是否和主域名的IP地址相近。一般再查詢域名是否存在CDN的話，我們可以看響應頭、或者看解析記錄，里面大多都有關于云端CDN的字眼。當然提倡寫腳本，Kali linux中也有工具 ~

 

 

 

第三個，社工DNS 比較苛刻，需要拿到CDN那邊的管理員權限開可以。

 

第四個，CDN節點分發缺陷，通過國外IP訪問網站可能會出現真實IP，因為有的CDN服務商可能只做了國內節點，沒做國外的，這樣訪問請求是直接被轉發到真實服務器地址上。

 

那么下面來概述一下得到了繞過的條件如何進行繞過，假設服務器端的IP地址為121.121.1x1.1x1，管理員設置了CDN節點，經過上面的方法得到真實IP地址后，可以直接更改本地的hosts文件來直接將數據發送到網站服務器上。這里不再詳細概述啦~

 

0x02 白名單應用（子域名）#

 

在有些時候，某些廠商的環境剛剛上線，用于調試項目，并沒有直接將子域名添加至CDN節點，那么就有可能出現某些安全隱患，因為剛上線的項目都沒有任何防御措施，如果當前項目與目標站點搭建在同一個服務器中，也會成為我們繞過WAF的有利條件。當然白名單應用不止一個上線項目，還有某些管理應用，例如：phpmyadmin，其操作完全不會被WAF攔截，當然應用過多，本人不才，只接觸一些常見的，歡迎補充。

 

第二篇 應用層過WAF

 

0x01 HTTP不同的請求方法污染#

 

> GET 請求指定的頁面信息，并返回實體主體。>> HEAD 類似于GET請求，只不過返回的響應中沒有具體的內容，用于獲取報頭>> POST 向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。>> PUT 從客戶端向服務器傳送的數據取代指定的文檔的內容。>> DELETE 請求服務器刪除指定的頁面。>> CONNECT HTTP/1.1協議中預留給能夠將連接改為管道方式的代理服務器。>> OPTIONS 允許客戶端查看服務器的性能。>> TRACE 回顯服務器收到的請求，主要用于測試或診斷。

 

我們可以先看一個請求：

 

 

 

可見是一個GET請求，此服務器是一個Apache+PHP的環境。

 

假設服務器只攔截

 

GET/POST

 

請求，那么根據Apache服務器的特性，發送其他請求只要腳本接收的是GET參數，那么也是可以傳遞參數值的。

 

如圖：

 

 

 

此知識點需要先知道各個Web服務器環境的特性，然后再針對特性去做測試。

 

0x02 GET與POST的區別#

 

Http定義了與服務器交互的不同方法，最基本的方法有4種，分別是GET，POST，PUT，DELETE。URL全稱是資源描述符，我們可以這樣認為：一個URL地址，它用于描述一個網絡上的資源，而HTTP中的GET，POST，PUT，DELETE就對應著對這個資源的查，改，增，刪4個操作。到這里，大家應該有個大概的了解了，GET一般用于獲取/查詢資源信息，而POST一般用于更新資源信息。

 

在網上已經有很多朋友寫過了其問題的答案，但是對于WAF，我們就要轉變角度去看了，第一點就是要看數據包的區別。

 

POST /sql/search.php HTTP/1.1
Host: 192.168.1.102
User-Agent: Mozilla/5.0 (windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Accept: text/html,Application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: http://192.168.1.102/sql/search.php
Cookie: yunsuo_session_verify=a89786c1a180124a6820b6387b85b693
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

keywords=t

 

POST /sql/search.php HTTP/1.1
Host: 192.168.1.102
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: http://192.168.1.102/sql/search.php
Cookie: yunsuo_session_verify=a89786c1a180124a6820b6387b85b693
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

keywords=t

 

可見在請求的數據包中，POST比GET多了一個

 

Content-Type: application/x-www-form-urlencoded

 

這個是將提交數據變成url編碼來傳遞給服務器，那么如此說來，也有的WAF會解析這行

 

Content-Type

 

去識別是否是POST注入，因為要防止方法污染。

 

如圖：

 

 

 

這樣也可以有幾率擾亂WAF的判斷。

 

0x03 文件上傳#

 

關于文件上傳我們來分享幾點，用于延伸下方HPP這一點。

 

先看一個上傳數據包。

 

POST /upload.php HTTP/1.1
Host: 192.168.1.100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: http://192.168.1.100/
Cookie:yunsuo_session_verify=1a9c7117538a7a9bce39a4695ff3f0cc; safedog-flow-item=
X-Forwarded-For: 1.1.1.1
CLIENT_IP: 2.2.2.2
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Content-Type:multipart/form-data; boundary=---------------------------440470572354
Content-Length: 1089

-----------------------------440470572354
Content-Disposition: form-data; name="file"; filename="n.php"
Content-Type: application/octet-stream

<?php
phpinfo();
?>
-----------------------------440470572354
Content-Disposition: form-data; name="submit"

Submit
-----------------------------440470572354--

 

Content-Type:multipart/form-data;

 

指代的是這個數據是來自表單提交的

 

某些WAF是通過Content-Type識別是否是文件上傳數據包。假設我們將Content-Type更改，數據包也是正常提交過去的。這個就完成了一次bypass。

 

還有的時候就是

 

Content-Disposition: form-data;

 

，也有某些WAF是根據Content-Disposition匹配

 

filename

 

的

 

（Safe Dog 3.5/4.0通殺）

 

，用于驗證黑名單。我們經過混淆大小寫也是可以bypass的。

 

攔截：

 

 

 

Bypass:

 

 

 

具體看

 

關于Safe DOG的文件上傳bypass**

 

0x04 **HTTP**參數污染（HPP）#

 

上一節已經講過了文件上傳，在HPP中最典型的的例子就是“雙文件上傳”。

 

就是在協議中，提交兩個相同的值，達到欺騙WAF一次匹配的目的。在這里提點一下http協議中參數名與參數值的結構。

 

[參數名]=“參數值”; 或者[參數名]=“參數值”亦或者[參數名]=參數值 亦或者[參數名]=參數值;

 

 

 

這類都會被解析，只要根據正規協議數據結構去構造數據包即可bypass。

 

我們來看一個例子：

 

 

 

這里已經被攔截，我們根據上述條件來修改數據包：

已經bypass成功了。

 

 

原文轉自：https://www.cnblogs.com/wh4am1/p/6545454.html