Hello there, ('ω')ノ
HTTPリクエストの密輸、基本的なCL.TEの脆弱性を。
このラボにはフロントエンドサーバとバックエンドサーバがあって。
フロントエンドサーバはチャンクエンコーディングをサポートしていないらしく。
さらには、GETまたはPOSTメソッドを使用していないリクエストを拒否して。
今回は、リクエストをバックエンドサーバに密輸して。
バックエンドサーバがGPOSTリクエストがメソッドを処理するようにと。
つまり、バックエンドサーバにGPOSTメソッドを受信させるだけでいいわけで。
サーバが解析中にエラーを報告実行する前に。
自動更新Content-Length関数をキャンセルしておいたほうがよいかと。
まずは、ラボにアクセスして。
リクエストをリピータへ。
GETをPOSTに変更して。
この理由は、のちほど理解できるはずで。
さらには、User-Agent:以降を削除して。
下記を追加して、Sendするとステータス200が。
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 6
Transfer-Encoding: chunked
0
G
もう一発、SendするとGPOSTの受信が確認できて。
クリアできた。
フロントエンドサーバがを処理するため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, (^^ゞ
