建站
咨詢
售后
建站咨詢
新聞中心
0X00前言
最近參加重保，和同事閑聊時(shí)間，談起來了外網(wǎng)，彼時(shí)信心滿滿，好歹我也是學(xué)了幾年，會不少的。結(jié)果，扭頭看完do9gy師傅的《騰訊 WAF 挑戰(zhàn)賽回憶錄》，就啪啪打臉了。說來慚愧，最近一段時(shí)間，拿到offer就開始飄起來了，現(xiàn)在悔不當(dāng)初，于是就想寫一篇關(guān)于這篇Http首部字段文章的"訓(xùn)詁篇"出來，一來當(dāng)做知識鞏固，二來算是完善些和首部字段相關(guān)的知識點(diǎn)（可會因?yàn)橐娮R不足，導(dǎo)致遺漏）。畢竟，小白可能這方面了解不多，只了解Cookie和Agent這種常見類型的首部字段，卻很少聽過Accept-Encoding和Content-Encoding這類不太常用的首字部。
專注于為中小企業(yè)提供網(wǎng)站建設(shè)、成都網(wǎng)站制作服務(wù),電腦端+手機(jī)端+微信端的三站合一,更高效的管理,為中小企業(yè)興城免費(fèi)做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了1000多家企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設(shè)實(shí)現(xiàn)規(guī)模擴(kuò)充和轉(zhuǎn)變。
0X01基礎(chǔ)知識
關(guān)于WAF的問題？
它是我們?nèi)粘９シ姥菥毐貢鲆姷?，在IOS七層模型中，WAF分為網(wǎng)絡(luò)層、應(yīng)用層的，當(dāng)然還有云 WAF（CDN+WAF）這新型類場景的。不同環(huán)境下我們繞過WAF的思路也是有所區(qū)別的，例如，對于傳統(tǒng)的網(wǎng)絡(luò)層 WAF，采用chunked編碼（即對內(nèi)容進(jìn)行所謂的"加密"）即可繞過，下次遇見的時(shí)候，我們?nèi)匀粐L試在網(wǎng)絡(luò)層這一類型上進(jìn)行嘗試和探索。
存在于應(yīng)用層的WAF，它們的處理引擎是經(jīng)過前端到達(dá)Apache（或者是Nginx）完成 HTTP協(xié)議初步解析后，再轉(zhuǎn)交給引擎處理的，這個(gè)時(shí)候網(wǎng)絡(luò)層的繞過技術(shù)是無效的。這就需要我們?nèi)パ芯浚簩τ谝粋€(gè) HTTP 請求，Nginx 解析了什么內(nèi)容？交給后面的 PHP、ASP 又解析了什么內(nèi)容？（探究到這個(gè)深度，就需要有良好的編程基礎(chǔ)和協(xié)議基礎(chǔ)，否則，后面及其吃力）。
至于最后的云WAF，我們可以簡單的看成CDN加上軟件WAF的結(jié)合體，既可以抗住DDos攻擊，也可以過濾出部分簡單的Payload攻擊代碼，甚至對流量也有一定的清洗作用。
HTTP首部的利用方式？
HTTP 請求頭Content-Type的charset編碼可以指定內(nèi)容編碼，在國內(nèi)大多數(shù)都是UTF-8編碼，但是攻擊者在攻擊的時(shí)候可以替換為 ibm037、 ibm500、cp875等不常用的"偏門"編碼來繞過WAF的檢測。我們也可以通過設(shè)置Content-Type頭的值為application/x-www-form或者multipart/form-data;charset=ibm500,boundary=blah等進(jìn)行繞過。
0X02首字部Encoding
關(guān)于Encoding，整個(gè)名稱應(yīng)該為Accept-Encoding；它在http協(xié)議中的作用是可以對內(nèi)容（也就是body部分）進(jìn)行編碼。Accept-Encoding: gzip：表示它可以采用gzip這樣的編碼，從而達(dá)到壓縮的目的。這樣的話關(guān)于網(wǎng)絡(luò)層的WAF是可以被繞過的，當(dāng)然我們也可以使用其他的編碼把內(nèi)容攪亂或加密，以此來防止未授權(quán)的第三方看到文檔的內(nèi)容。當(dāng)服務(wù)端接收到請求，并且從Header里拿到編碼標(biāo)識時(shí)，就可以選擇其中一種方式來進(jìn)行編碼壓縮，然后返給客戶端。
瀏覽器發(fā)給服務(wù)器,聲明瀏覽器（客戶端）支持的編碼類型解釋
Accept-Encoding設(shè)置在請求頭當(dāng)中，會告訴服務(wù)器，我可以接受哪種編碼壓縮
Content-Encoding設(shè)置在響應(yīng)頭中，會告訴客戶端，我用的是哪種編碼壓縮
?小提示：Encoding?的大概意思是：決定文件接收方將以什么形式、什么編碼讀取這個(gè)文件，指定服務(wù)器響應(yīng)的 HTTP 內(nèi)容類型；這兩個(gè)header頭都會影響服務(wù)器對于數(shù)據(jù)內(nèi)容的傳輸格式類型（壓縮算法）；文章：參考鏈接！
小提示：Accept-Encoding: deflate?但發(fā)現(xiàn)這種方法已經(jīng)過時(shí)了，我們可以換成Accept-Encoding: gzip，發(fā)現(xiàn)上傳成功。
加密繞過
分塊傳輸繞過
如果在HTTP首字部中加入Transfer-Encoding: chunked。我們就可以利用這個(gè)報(bào)文采用了分塊編碼的方式繞過應(yīng)用層面的WAF。原因的這時(shí)是通過POST請求報(bào)文中的數(shù)據(jù)部分，并對數(shù)據(jù)進(jìn)行分塊傳輸。每個(gè)分塊包含十六進(jìn)制的長度值和數(shù)據(jù)，長度值獨(dú)占一行，長度不包括它結(jié)尾的，也不包括分塊數(shù)據(jù)結(jié)尾的，且最后需要用0獨(dú)占一行表示結(jié)束（同時(shí)末尾需要以兩個(gè)換行結(jié)束）。
小提示：上傳失敗的原因是沒有分好考塊，這種可以在繞過SQL注入或者XSS的時(shí)候進(jìn)行嘗試，不建議和上圖一樣對圖片馬進(jìn)行嘗試（關(guān)鍵是不好分塊，效率低下）。
0X03首字部Pipeline
眾所周知，HTTP協(xié)議是由TCP協(xié)議封裝而來，當(dāng)瀏覽器發(fā)起一個(gè)HTTP請求時(shí)，瀏覽器先與服務(wù)器通過TCP協(xié)議建立連接，然后發(fā)送HTTP 數(shù)據(jù)包給它，但是這里包含了一個(gè)Connection的字段，正常情況下該段的值為close。而且Apache等Web容器會根據(jù)這個(gè)字段決定是保持該 TCP 連接或是斷開。當(dāng)發(fā)送的內(nèi)容太大，超過一個(gè) HTTP 包容量，需要分多次發(fā)送時(shí)，值會變成keep-alive，即本次發(fā)起的 HTTP 請求所建立的TCP連接不斷開，直到所發(fā)送內(nèi)容結(jié)束Connection為close時(shí)停止。
0X04首字部Disposition
Content-Disposition的具體原理：它是WAF的一個(gè)規(guī)則，針對文件上傳主要是對那個(gè)地方去做防護(hù)的，所以需要混淆去繞過！?。?/p>
由于該協(xié)議對 PHP 對解析存在缺陷、使得如果一行有多個(gè) filename 字段值，則PHP構(gòu)造的Web Server會取最后的filename值進(jìn)行解析。Web Server最終可以得到的文件名是1.php，但是某些WAF只會判新第一個(gè)filename的值，因此 WAF 對上傳的文件的過濾檢測功能會被黑客繞過，并且這里的form-data是可有可無的類型，就是去掉它也不會影響Web Server獲取filename的名稱（如下所示）：
Content-Disposition: form-data; name="file1"; filename="1.txt";filename="1.php";
雖是如此，但filename的編碼還會被HTTP請求Content-Type頭中charset所影響；Web Server可以根據(jù)這個(gè)值進(jìn)行響應(yīng)的解碼處理。這些都有可能被一些人稍微做點(diǎn)手腳，便可以繞過不少WAF的文件上傳過濾檢測。可能有的師傅會說，那怎么測試??？這個(gè)其實(shí)就見仁見智了，我通常會自己搭建一個(gè)環(huán)境進(jìn)行Fuzzing字典的黑盒測試；如果是代碼審計(jì)和CTF功底好的師傅，可能就直接測試一些漏洞點(diǎn)了。所以，這方面大家可以多看看，其他師傅寫的文章，平時(shí)多學(xué)習(xí)多做筆記了。
0X05首字部Typer
Content-Type：一般是指網(wǎng)頁中存在的Content-Type，用于定義網(wǎng)絡(luò)文件的類型和網(wǎng)頁的編碼，決定文件接收方將以什么形式、什么編碼讀取這個(gè)文件，這就是經(jīng)?？吹揭恍〢sp網(wǎng)頁點(diǎn)擊的結(jié)果卻是下載到的一個(gè)文件或一張圖片的原因。
特殊編碼繞過
HTTP頭里的Content-Type請求頭一般有application/x-www-form-urlencoded，multipart/form-data，text/plain三種，其中multipart/form-data表示數(shù)據(jù)被編碼為一條消息，頁上的每個(gè)控件對應(yīng)消息中的一個(gè)部分。當(dāng) WAF 沒有規(guī)則匹配該協(xié)議傳輸?shù)臄?shù)據(jù)時(shí)則可被繞過。
利用特殊編碼對payload進(jìn)行轉(zhuǎn)義，從而繞過WAF對特殊關(guān)鍵詞的過濾。該方法的思路主要圍繞： multipart/form-data進(jìn)行，主要針對于 POST 參數(shù)的，對于需要在GET參數(shù)位置觸發(fā)的惡意漏洞影響不大。說起multipart/form-data 的作用，我們知道HTTP 協(xié)議POST請求，除了常規(guī)的 application/x-www-form-urlencoded 以外，還有 multipart/form-data 這種形式，就是為了解決上傳文件場景的問題下文件內(nèi)容較大且內(nèi)置字符不可控的問題而準(zhǔn)備的。multipart/form-data 格式也是可以傳遞POST參數(shù)的。對于Nginx+PHP的架構(gòu)，Nginx 實(shí)際上是不負(fù)責(zé)解析 multipart/form-data 的 body 部分的，而是交由 PHP 來解析，因此 WAF 所獲取的內(nèi)容就很有可能與后端的 PHP 發(fā)生不一致。
以 PHP 為例，我們寫一個(gè)簡單的測試腳本：
//用于將文件的內(nèi)容讀入到一個(gè)字符串中
echo file_get_contents("php://input");
//打印顯示，一個(gè)變量的內(nèi)容與結(jié)構(gòu)
var_dump($_POST);
//打印顯示，一個(gè)變量的類型的信息
var_dump($_FILES);
?>
雙寫上傳描述行繞過
雙寫整個(gè)Part開頭繞過
構(gòu)造假的Part繞過
雙寫B(tài)oundary繞過
構(gòu)造空Boundary繞過
構(gòu)造空格+Boundary繞過
雙寫Content-Type繞過
Boundary+逗號繞過
小提示：Bypass WAF 的核心思想在于，一些 WAF 產(chǎn)品處于降低誤報(bào)考慮，對用戶上傳文件的內(nèi)容不做匹配，直接放行。事實(shí)上，這些內(nèi)容在絕大多數(shù)場景也無法引起攻擊。但關(guān)鍵問題在于，WAF 能否準(zhǔn)確有效識別出哪些內(nèi)容是傳給$POST 數(shù)組的，哪些傳給$FILES 數(shù)組？如果不能，那我們是否就可以想辦法讓 WAF 以為我們是在上傳文件，而實(shí)際上卻是在 POST一個(gè)參數(shù)，這個(gè)參數(shù)可以是命令注入、SQL 注入、SSRF 等任意的一種攻擊，這樣就實(shí)現(xiàn)了通用 WAF Bypass。
0X06首字部Filename
截?cái)郌ilename繞過
首先將原始的帶有臟數(shù)據(jù)的 payload 轉(zhuǎn)換成文件上傳包格式的協(xié)議：multipart/form-data，然后進(jìn)行截?cái)?，如下圖所示：
以上環(huán)境并未演示到另外一種基于 HTTP 協(xié)議特性繞過 WAF 的方法（實(shí)際上是基于 “協(xié)議未覆蓋繞過” 方法，屬于它的升級改造版）——filename 文件名混淆繞過。下面直接看漏洞銀行大佬在視頻中的實(shí)戰(zhàn)利用演示。
空格+filename繞過
為了讓 Payload 能夠順利解析，可以在 fliename="1.jpg"的等號前面添加空格，讓 fliename 文件名無法解析，從而使得后面的php參數(shù)可被服務(wù)器解析執(zhí)行，最終達(dá)到繞過 WAF 同時(shí)執(zhí)行 pqyload 注入的目的：
雙引號+filename繞過
另外此處也可以在 filename 前方添加雙引號，也可以實(shí)現(xiàn)上述執(zhí)行 payload 的目的：
0X07小結(jié)
通過上述學(xué)習(xí)，我們知道了關(guān)于HTTP首字部的一些知識點(diǎn)，進(jìn)而通過利用該首字部的特點(diǎn)進(jìn)行Fuzzing，最終達(dá)到繞過WAF的目的。當(dāng)然上述結(jié)論難免存在不足，希望師傅們斧正。經(jīng)過這幾天的資料查找，我發(fā)現(xiàn)這些東西在CTF領(lǐng)域的研究，以及達(dá)到了登峰造極的地步。而且我們真正的去理解這些東西，可能需要掌握好一門語言和對HTTP協(xié)議有所了解（導(dǎo)致我的解釋可能過于牽強(qiáng)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
當(dāng)前標(biāo)題：HTTP繞WAF之淺嘗輒止
轉(zhuǎn)載來于：http://www.dlmjj.cn/article/dhsphgc.html
