HTTP請求走私詳解

http://dy.163.com/v2/article/detail/F4OE9JKC0511CJ6O.html

　　

　　

　　HTTP請求走私是一種干擾網站處理HTTP請求序列方式的技術，使攻擊者能夠繞過安全控制，未經受權訪問敏感數據並直接危害其餘應用程序用戶。請求走私大多發生於前端服務器和後端服務器對客戶端傳入的數據理解不一致的狀況。這是由於HTTP規範提供了兩種不一樣的方法來指定請求的結束位置，即 Content-Length 和 Transfer-Encoding標頭。

　　HTTP請求走私不是一個新問題，Watchfire（一家安全軟件測試公司，2018年被IBM收購）於2005年發佈的白皮書就對此進行了詳細討論，除此以外，還有其餘介紹HTTP請求走私的資源。但我發現，這些資源缺乏的是實用的，可行的參考指南。

　　這篇文章介紹了個人發現，但願你能對HTTP請求走私的複雜性有更深地瞭解。

　　最近我測試了一個web應用程序，它彷佛容易受到HTTP請求走私的攻擊，我不只要識別漏洞並向客戶證實它的存在，還要在實際操做中演示它。

　　
HTTP請求走私的攻擊方式

　　使用HTTP請求走私的攻擊方法有不少，例如跨站點腳本（XSS），其中攻擊者以應用程序的用戶爲目標，而不是攻擊者直接以用戶爲目標。另外還有會話劫持以及服務器端請求僞造（SSRF）。此外，我相信還存在其餘仍須要探索的攻擊方法。

　　不過，請求走私也有不一樣的變體，這些變體由表示攻擊中使用的標頭的縮寫而爲人所知。好比CL：CL， CL：TE， TE：TE和TE：CL。CL表示標頭值Content-Length，TE表示報頭傳輸編碼。本文爲了方便講解，本文將僅介紹一種請求走私方法的細節。

　　我將在本文中演示的HTTP請求走私方法稱爲CL：TE，而且使用此方法，我將執行後端套接字攻擊。

　　
發現走私請求

　　使用Burp Suite Web代理瀏覽Web應用程序時，你可能會注意到在「儀表板」選項卡中標記了HTTP請求走私。因爲缺少理解，這一般被忽略或被視爲誤報。

　　的確，有時此漏洞可能很難被利用和演示，可是經過本文，我但願你對這個概念有個清楚地瞭解。

　　首先，讓咱們看看由Burp Suite標記的HTTP請求走私。

　　

　　當它發送具備格式錯誤的內容長度和傳輸編碼頭的請求時，Burp將其標記爲HTTP請求走私。當其中一個響應超時時，Burp將把它標記爲HTTP請求走私。

　　以下面的屏幕截圖所示，該請求沒有響應選項卡，代表該請求已超時而且存在HTTP請求走私。

　　

　　
如何證實HTTP請求走私攻擊的存在

　　一旦Burp標記了HTTP請求走私，咱們須要確認它確實存在，而且沒有誤報。

　　發送有效請求的過程以下圖所示：

　　

　　從上面能夠看出，發送了一個有效的請求。前端重寫請求，添加後端所需的標頭信息，後端處理此請求並返回預期的響應。

　　所以，要檢測到咱們發現了HTTP請求走私，咱們必須發送格式錯誤的請求。爲此，在下面的示例中，咱們在「 Transfer-Encoding」標頭和後面的冒號之間添加一個空格。前端將忽略「傳輸編碼：分塊」，並使用「內容長度」來肯定請求是否有效。而後，前端重寫標頭並刪除使此傳輸編碼標頭在發送到後端請求時有效的空間。在本例中，傳輸編碼頭到達後端時優先於內容長度標頭。

　　下圖說明了這一點：

　　

　　
演示

　　下面的截圖演示了一個惡意請求，其中有變形的「傳輸編碼」標頭，在請求主體的開始處有一個「0」來終止後端請求，還有一個「X」用來攻擊後端套接字。

　　

　　若是咱們將其加載到Intruder中，並在響應中查找「405」錯誤，則代表咱們已成功用初始請求攻擊了後端套接字。

　　

　　如上所示，顯示了一個「405方法不容許」響應。這是由於下一個啓動的請求是「XPOST / HTTP/1.1」，所以不是一個有效的請求。

　　至此能夠確認，請求走私確實存在！

　　
PoC

　　從以上的介紹中咱們能夠發現，有許多能夠與請求走私一塊兒使用的攻擊，這些攻擊包括：

　　1.將XSS映射到站點範圍的XSS；

　　2.會話劫持和賬戶接管；

　　3.SSRF；

　　4.緩存攻擊；

　　5.顯示前端請求重寫；

　　我將在如下示例中演示的利用方法是會話劫持和賬戶接管。

　　可是，隨着請求走私攻擊的發生，全部這些信息就從窗口中消失了，這些cookie再也不受到保護！此方法還將顯示前端請求重寫。

　　爲了可以利用HTTP請求走私並劫持會話，攻擊須要知足一些先決條件：

　　1. CL:TE 後端套接字攻擊；

　　2.請求的一部分應反映在響應中；

　　咱們須要找到一個請求，該請求的一部分反映在響應中。在此示例中，我移動了「maincontent_0%24firstname=」 參數，並將其轉換爲請求中的最後一個參數。

　　如下是POST請求有效載荷的後半部分，其中maincontent_0%24firstname=」 是請求中的最後一個參數：

　　

　　檢查這個POST請求的響應是否在響應中呈現X字符串，若是該字符串被呈現，這將是響應體中的字段，咱們將在該字段中找到被利用的用戶的請求。

　　下面的屏幕截圖確認了POST請求的最後一個參數字段中的全部內容都將呈如今響應字段中。

　　如今，咱們能夠確認

　　1.後端套接字能夠被攻擊；

　　2.具備有效的POST請求參數輸入，該輸入將呈如今響應字段中；

　　而後，咱們能夠走私該請求，對後端套接字進行攻擊。而後，對服務器的下一個請求將附加到咱們的走私請求中，並在如上所示的相同響應字段中對咱們進行響應。

　　讓咱們先看看咱們的請求，該請求的走私有效載荷以下（藍色文本）：

　　

　　從上圖能夠看出，這裏的請求管道中的第一個請求是有效的發佈請求。第二個藍色是咱們走私的有效載荷。

　　我已經在走私的有效載荷中突出顯示了內容長度，由於咱們但願添加比請求體中更多的內容長度，這是由於咱們須要給被利用的用戶請求一些空間，以便將其放置在響應字段中。

　　
攻擊利用

　　咱們將帶有有效載荷的請求加載到Intruder中，運行時，咱們將看到響應內容的長度不一樣。在咱們發送連續請求時，某些攻擊者會返回咱們本身的響應。可是，若是毫無戒心的用戶使用該應用程序，咱們將捕獲他們發送的請求。他們發送的這些請求將被寫入到咱們的有效載荷的末尾，並反映在咱們接收到的響應字段中。

　　下面顯示的是Intruder的輸出。返回的響應長度不一樣，代表咱們已經成功利用了用戶，只要他們在咱們在Intruder中運行該利用程序的同時就一直在使用該應用程序。

　　

　　查看咱們在Intruder中找到的響應後，咱們能夠看到用戶已將其請求附加到咱們的有效載荷中。下圖顯示了來自用戶的GET請求，該請求的所有內容都呈如今咱們的響應字段中。

　　

　　所以，若是有人正在使用應用程序，就不須要針對特定的用戶。若是有效載荷正在Intruder中運行，而且有人將請求發送到服務器，咱們將捕獲該請求。它將添加到咱們的走私請求中，而後咱們能夠竊取他們的會話cookie並劫持他們的賬戶。

　　本文參考自：https://www.pentestpartners.com/security-blog/http-request-smuggling-a-how-to/