HTTP繞WAF之淺嘗輒止
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設置在響應頭中，會告訴客戶端，我用的是哪種編碼壓縮
?小提示：Encoding?的大概意思是：決定文件接收方將以什么形式、什么編碼讀取這個文件，指定服務器響應的 HTTP 內容類型；這兩個header頭都會影響服務器對于數據內容的傳輸格式類型（壓縮算法）；文章：參考鏈接！
小提示：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
