shikata ga nai

Private? There is no such things.

HTTP request smuggling, basic CL.TE vulnerabilityをやってみた

Hello there, ('ω')ノ

 

HTTPリクエストの密輸、基本的なCL.TEの脆弱性を。

このラボにはフロントエンドサーバとバックエンドサーバがあって。

フロントエンドサーバはチャンクエンコーディングをサポートしていないらしく。

さらには、GETまたはPOSTメソッドを使用していないリクエストを拒否して。

今回は、リクエストをバックエンドサーバに密輸して。

バックエンドサーバがGPOSTリクエストがメソッドを処理するようにと。

つまり、バックエンドサーバにGPOSTメソッドを受信させるだけでいいわけで。

 

サーバが解析中にエラーを報告実行する前に。

自動更新Content-Length関数をキャンセルしておいたほうがよいかと。

 

f:id:ThisIsOne:20210307173002p:plain

 

まずは、ラボにアクセスして。

 

f:id:ThisIsOne:20210307180716p:plain

 

リクエストをリピータへ。

 

f:id:ThisIsOne:20210307180651p:plain

 

GETをPOSTに変更して。

この理由は、のちほど理解できるはずで。

さらには、User-Agent:以降を削除して。

 

f:id:ThisIsOne:20210307181026p:plain

 

下記を追加して、Sendするとステータス200が。

 

Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 6
Transfer-Encoding: chunked

0

G

 

f:id:ThisIsOne:20210307181121p:plain

 

もう一発、SendするとGPOSTの受信が確認できて。

 

f:id:ThisIsOne:20210307181146p:plain

 

クリアできた。

 

f:id:ThisIsOne:20210307181211p:plain

フロントエンドサーバがを処理するためContent-Lengthは。

リクエスト本文の長さは6バイトで。

HTTPやメールのプロトコルでは改行コードとしてCRLF(\r\n)が使われるので。

下記のようになって。

 

0\r\n
\r\n
G

 

要求パケットがバックエンドサーバに転送されると。

バックエンドサーバはTransfer-Encodingを処理して。

0\r\n\r\nを読み取ると、それが最後Gに到達したと見なして。

G文字をバッファに残して、次の要求が到着するのを待って。

リクエストを繰り返し送信すると、送信されたリクエストは。

下記のリクエストに組み込まれまて。

 

GPOST / HTTP/1.1\r\n
Host: ace01fcf1fd05faf80c21f8b00ea006b.web-security-academy.net\r\n
......

 

するとサーバが解析中にエラーを報告して。

基本的な例として。


CL.TE:

 フロントエンドサーバはContent-Lengthヘッダを使用して。

 バックエンドサーバはTransfer-Encodingヘッダを使用して。

 

best regards, (^^ゞ

ひとりひとりの自覚をもった行動で、医療従事者と保健所職員を助けよう。

f:id:ThisIsOne:20200404115457p:plain