鑽石舞台

0X00前言

最近參加重保，和同事閒聊時間，談起來了外網，彼時信心滿滿，好歹我也是學了幾年，會不少的。結果，扭頭看完do9gy師傅的《騰訊 WAF 挑戰賽回憶錄》，就啪啪打臉了。說來慚愧，最近一段時間，拿到offer就開始飄起來了，現在悔不當初，於是就想寫一篇關於這篇Http首部字段文章的"訓詁篇"出來，一來當做知識鞏固，二來算是完善些和首部字段相關的知識點（可會因為見識不足，導致遺漏）。畢竟，小白可能這方面了解不多，只了解Cookie和Agent這種常見類型的首部字段，卻很少聽過Accept-Encoding和Content-Encoding這類不太常用的首字部。

0X01基礎知識關於WAF的問題？

它是我們日常攻防演練必會遇見的，在IOS七層模型中，WAF分為網絡層、應用層的，當然還有雲 WAF（CDN+WAF）這新型類場景的。不同環境下我們繞過WAF的思路也是有所區別的，例如，對於傳統的網絡層 WAF，採用chunked編碼（即對內容進行所謂的"加密"）即可繞過，下次遇見的時候，我們仍然嘗試在網絡層這一類型上進行嘗試和探索。

存在於應用層的WAF，它們的處理引擎是經過前端到達Apache（或者是Nginx）完成 HTTP協議初步解析後，再轉交給引擎處理的，這個時候網絡層的繞過技術是無效的。這就需要我們去研究：對於一個 HTTP 請求，Nginx 解析了什麼內容？交給後面的 PHP、ASP 又解析了什麼內容？（探究到這個深度，就需要有良好的編程基礎和協議基礎，否則，後面及其吃力）。

至於最後的雲WAF，我們可以簡單的看成CDN加上軟件WAF的結合體，既可以抗住DDos攻擊，也可以過濾出部分簡單的Payload攻擊代碼，甚至對流量也有一定的清洗作用。

HTTP首部的利用方式？

HTTP 請求頭Content-Type的charset編碼可以指定內容編碼，在國內大多數都是UTF-8編碼，但是攻擊者在攻擊的時候可以替換為 ibm037、 ibm500、cp875等不常用的"偏門"編碼來繞過WAF的檢測。我們也可以通過設置Content-Type頭的值為application/x-www-form或者multipart/form-data;charset=ibm500,boundary=blah等進行繞過。

0X02首字部Encoding

關於Encoding，整個名稱應該為Accept-Encoding；它在http協議中的作用是可以對內容（也就是body部分）進行編碼。Accept-Encoding: gzip：表示它可以採用gzip這樣的編碼，從而達到壓縮的目的。這樣的話關於網絡層的WAF是可以被繞過的，當然我們也可以使用其他的編碼把內容攪亂或加密，以此來防止未授權的第三方看到文檔的內容。當服務端接收到請求，並且從Header里拿到編碼標識時，就可以選擇其中一種方式來進行編碼壓縮，然後返給客戶端。

瀏覽器發給服務器,聲明瀏覽器（客戶端）支持的編碼類型解釋

Accept-Encoding設置在請求頭當中，會告訴服務器，我可以接受哪種編碼壓縮

Content-Encoding設置在響應頭中，會告訴客戶端，我用的是哪種編碼壓縮

小提示：Accept-Encoding: deflate但發現這種方法已經過時了，我們可以換成Accept-Encoding: gzip，發現上傳成功。

加密繞過

分塊傳輸繞過

如果在HTTP首字部中加入Transfer-Encoding: chunked。我們就可以利用這個報文採用了分塊編碼的方式繞過應用層面的WAF。原因的這時是通過POST請求報文中的數據部分，並對數據進行分塊傳輸。每個分塊包含十六進制的長度值和數據，長度值獨占一行，長度不包括它結尾的，也不包括分塊數據結尾的，且最後需要用0獨占一行表示結束（同時末尾需要以兩個換行結束）。

小提示：上傳失敗的原因是沒有分好考塊，這種可以在繞過SQL注入或者XSS的時候進行嘗試，不建議和上圖一樣對圖片馬進行嘗試（關鍵是不好分塊，效率低下）。

0X03首字部Pipeline

眾所周知，HTTP協議是由TCP協議封裝而來，當瀏覽器發起一個HTTP請求時，瀏覽器先與服務器通過TCP協議建立連接，然後發送HTTP 數據包給它，但是這裡包含了一個Connection的字段，正常情況下該段的值為close。而且Apache等Web容器會根據這個字段決定是保持該 TCP 連接或是斷開。當發送的內容太大，超過一個 HTTP 包容量，需要分多次發送時，值會變成keep-alive，即本次發起的 HTTP 請求所建立的TCP連接不斷開，直到所發送內容結束Connection為close時停止。

0X04首字部Disposition

Content-Disposition的具體原理：它是WAF的一個規則，針對文件上傳主要是對那個地方去做防護的，所以需要混淆去繞過！！！

由於該協議對 PHP 對解析存在缺陷、使得如果一行有多個 filename 字段值，則PHP構造的Web Server會取最後的filename值進行解析。Web Server最終可以得到的文件名是1.php，但是某些WAF只會判新第一個filename的值，因此 WAF 對上傳的文件的過濾檢測功能會被黑客繞過，並且這裡的form-data是可有可無的類型，就是去掉它也不會影響Web Server獲取filename的名稱（如下所示）：

雖是如此，但filename的編碼還會被HTTP請求Content-Type頭中charset所影響；Web Server可以根據這個值進行響應的解碼處理。這些都有可能被一些人稍微做點手腳，便可以繞過不少WAF的文件上傳過濾檢測。可能有的師傅會說，那怎麼測試啊？這個其實就見仁見智了，我通常會自己搭建一個環境進行Fuzzing字典的黑盒測試；如果是代碼審計和CTF功底好的師傅，可能就直接測試一些漏洞點了。所以，這方面大家可以多看看，其他師傅寫的文章，平時多學習多做筆記了。

0X05首字部Typer

Content-Type：一般是指網頁中存在的Content-Type，用於定義網絡文件的類型和網頁的編碼，決定文件接收方將以什麼形式、什麼編碼讀取這個文件，這就是經常看到一些Asp網頁點擊的結果卻是下載到的一個文件或一張圖片的原因。

特殊編碼繞過

HTTP頭裡的Content-Type請求頭一般有application/x-www-form-urlencoded，multipart/form-data，text/plain三種，其中multipart/form-data表示數據被編碼為一條消息，頁上的每個控件對應消息中的一個部分。當 WAF 沒有規則匹配該協議傳輸的數據時則可被繞過。

利用特殊編碼對payload進行轉義，從而繞過WAF對特殊關鍵詞的過濾。該方法的思路主要圍繞：multipart/form-data進行，主要針對於 POST 參數的，對於需要在GET參數位置觸發的惡意漏洞影響不大。說起multipart/form-data 的作用，我們知道HTTP 協議POST請求，除了常規的 application/x-www-form-urlencoded 以外，還有 multipart/form-data 這種形式，就是為了解決上傳文件場景的問題下文件內容較大且內置字符不可控的問題而準備的。multipart/form-data 格式也是可以傳遞POST參數的。對於Nginx+PHP的架構，Nginx 實際上是不負責解析 multipart/form-data 的 body 部分的，而是交由 PHP 來解析，因此 WAF 所獲取的內容就很有可能與後端的 PHP 發生不一致。

以 PHP 為例，我們寫一個簡單的測試腳本：

雙寫上傳描述行繞過

雙寫整個Part開頭繞過

構造假的Part繞過雙寫Boundary繞過構造空Boundary繞過構造空格+Boundary繞過雙寫Content-Type繞過Boundary+逗號繞過

小提示：Bypass WAF 的核心思想在於，一些 WAF 產品處於降低誤報考慮，對用戶上傳文件的內容不做匹配，直接放行。事實上，這些內容在絕大多數場景也無法引起攻擊。但關鍵問題在於，WAF 能否準確有效識別出哪些內容是傳給$POST 數組的，哪些傳給$FILES 數組？如果不能，那我們是否就可以想辦法讓 WAF 以為我們是在上傳文件，而實際上卻是在 POST一個參數，這個參數可以是命令注入、SQL 注入、SSRF 等任意的一種攻擊，這樣就實現了通用 WAF Bypass。

0X06首字部Filename截斷Filename繞過

首先將原始的帶有髒數據的 payload 轉換成文件上傳包格式的協議：multipart/form-data，然後進行截斷，如下圖所示：

以上環境並未演示到另外一種基於 HTTP 協議特性繞過 WAF 的方法（實際上是基於 「協議未覆蓋繞過」 方法，屬於它的升級改造版）——filename 文件名混淆繞過。下面直接看漏洞銀行大佬在視頻中的實戰利用演示。

空格+filename繞過

為了讓 Payload 能夠順利解析，可以在 fliename="1.jpg"的等號前面添加空格，讓 fliename 文件名無法解析，從而使得後面的php參數可被服務器解析執行，最終達到繞過 WAF 同時執行 pqyload 注入的目的：

雙引號+filename繞過

另外此處也可以在 filename 前方添加雙引號，也可以實現上述執行 payload 的目的：

0X07小結

通過上述學習，我們知道了關於HTTP首字部的一些知識點，進而通過利用該首字部的特點進行Fuzzing，最終達到繞過WAF的目的。當然上述結論難免存在不足，希望師傅們斧正。經過這幾天的資料查找，我發現這些東西在CTF領域的研究，以及達到了登峰造極的地步。而且我們真正的去理解這些東西，可能需要掌握好一門語言和對HTTP協議有所了解（導致我的解釋可能過於牽強dog），希望大家不要介意！

參考鏈接：

https://www.freebuf.com/news/193659.html

https://www.cnblogs.com/zzjdbk/p/13936278.html

https://github.com/LandGrey/abuse-ssl-bypass-waf

https://hakin9.org/bypassing-wafs-with-wafninja-free-course-content/

https://hacken.io/discover/how-to-bypass-waf-hackenproof-cheat-sheet/

https://www.notsoshant.io/blog/bypassing-waf-by-playing-with-parameters/

https://infosecwriteups.com/waf-bypasses-tearing-down-the-wall-d08fd0f8374a

加個好友進滲透技術交流群

請備註：進群

歡迎在看丨留言丨分享至朋友圈三連