0x01 前言
在講本課的內容之前我們先來了解互聯網中的HTTP是什么？
超文本傳輸協議（HTTP，HyperText Transfer Protocol)是互聯網上應用最為廣泛的一種網絡協議。所有的WWW文件都必須遵守這個標准。設計HTTP最初的目的是為了提供一種發布和接收HTML頁面的方法。1960年美國人Ted Nelson構思了一種通過計算機處理文本信息的方法，並稱之為超文本（hypertext）,這成為了HTTP超文本傳輸協議標准架構的發展根基。Ted Nelson組織協調萬維網協會（World Wide Web Consortium）和互聯網工程工作小組（Internet Engineering Task Force ）共同合作研究，最終發布了一系列的RFC，其中著名的RFC 2616定義了HTTP 1.1。（百度的）
HTTP協議的主要特點
1.支持客戶/服務器模式。
2.簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯系的類型不同。由於HTTP協議簡單，使得HTTP服務器的程序規模小，因而通信速度很快。
3.靈活：HTTP允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
4.無連接：無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答后，即斷開連接。采用這種方式可以節省傳輸時間。
5.無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味着如果后續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就較快。
0x02 HTTP協議基礎講解
http請求由三部分組成，分別是：請求行、消息報頭、請求正文
請求行以一個方法符號開頭，以空格分開，后面跟着請求的URI和協議的版本，格式如下：Method Request-URI HTTP-Version CRLF其中 Method表示請求方法；Request-URI是一個統一資源標識符；HTTP-Version表示請求的HTTP協議版本；CRLF表示回車和換行（除了作為結尾的CRLF外，不允許出現單獨的CR或LF字符）。
0x03 HTTP請求方法
GET 請求指定的頁面信息，並返回實體主體。
HEAD 類似於get請求，只不過返回的響應中沒有具體的內容，用於獲取報頭
POST 向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。
PUT 從客戶端向服務器傳送的數據取代指定的文檔的內容。
DELETE 請求服務器刪除指定的頁面。
CONNECT HTTP/1.1協議中預留給能夠將連接改為管道方式的代理服務器。
OPTIONS 允許客戶端查看服務器的性能。TRACE 回顯服務器收到的請求，主要用於測試或診斷。
0x04 HTTP請求行區別
Http定義了與服務器交互的不同方法，最基本的方法有4種，分別是GET，POST，PUT，DELETE。
對應HTTP中的GET，POST，PUT，DELETE就對應着對這個資源的查，改，增，刪4個操作。
現在用的比較多的是post和get方式，一般情況下，如果不說明請求方式，例如地址欄輸入網址請求、
超鏈接請求等都是get請求，只有在form表單請求時可以設置method方式為post。
get請求方式請求數據顯示在url后面，post方式顯示在請求體中，空白行下面。
get方式請求數據有限制，最大為1k，而post方式理論上沒有限制。
在繞WAF中 GET包 與 POST包在處理上是有區別的，先看GET與POST的區別
Content-Type： 實體報頭域用語指明發送給接收者的實體正文的媒體類型
現在市場上大部分的WAF會解析這行 Content-Type 去識別是否是POST注入，因為要防止方法污染。所以我們就可以根據這個特性來設置不同的Content-Type利用嘗試繞過WAF
0x05 協議未覆蓋繞過WAF
POST 請求常用有2種參數提交方式：
Content-Type: application/x-www-form-urlencoded;
Content-Type: multipart/form-data;
Waf未能覆蓋Content-Type: multipart/form-data從而導致被繞過。或者WAF會認為它是文件上傳請求，從而只檢測文件上傳，導致被繞過。如圖，下面的WAF就存在被繞過的情況，是典型的協議未覆蓋。
0x06 例子一：實戰繞過雲鎖win_3.1.6版注入(針對POST請求)
我們前面說了大部分的WAF現在會去檢測Content-Type 來判斷當前執行的操作是什么那么如果我們修改他使用的是其他的報頭一定程度上就可能可以繞過WAF
0x07 例子二：實戰繞過360主機衛士2.0.4.6apache版進行注入(針對GET請求)
至於為什么可以繞過我這里猜想了一下：
雲鎖：
我這里猜想的想是因為 雲鎖在檢測的時候判斷問題，因為我們知道Content-Type:multipart/form-data; 是用於POST文件上傳的，所以雲鎖檢測到這個報文是上傳表單的請求，就調用了上傳 表單相對應的規則來檢測，而忽略了我們在上傳表單中一樣可以傳輸POST數組寫入惡意代碼，所以我們才能注入。
360主機衛士
360衛士的話，就比較簡單了，估計程序猿是使用了慣性思維，在寫代碼的時候判斷我們是POST請求就將重點放在POST數組中進行檢測，忘記了我們有可能在傳輸POST數據的時候，在URL寫入惡意代碼，導致防護失效
0x08 總結
繞waf一定要思路騷，http協議也一定要了解，了解了http協議在了解WAF 的工作原理，我們必須正視的是，繞waf就是在繞正則，所以正則表達式一定要入門，只有這樣你繞waf的時候才能腦補規則,干起活來也才能事半功倍。
哦對了，可能會有人想要我上面的那個工具，我會上傳到百度雲 : )
下載地址：http://pan.baidu.com/s/1c1Fpfhu
轉載請獲取作者同意在進行轉載謝謝 : )
作者：PHPoop
鏈接：http://www.jianshu.com/p/06eeb2ed4c9d
來源：簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。