HTTP Response Smuggling / Desync

Reading time: 13 minutes

この投稿の技術は、次のビデオから取得されました: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s

HTTPリクエストキューの非同期化

まず、この技術はHTTPリクエストスムージングの脆弱性を悪用しますので、それが何であるかを知っておく必要があります：

この技術と一般的なHTTPリクエストスムージングの主な違いは、攻撃するのではなく、被害者が受け取るレスポンスを漏洩または変更することです。これは、HTTPリクエストスムージングを悪用するために1.5リクエストを送信する代わりに、プロキシのレスポンスキューを非同期化するために2つの完全なリクエストを送信します。

これは、レスポンスキューを非同期化することができるため、被害者の正当なリクエストからのレスポンスが攻撃者に送信されるか、攻撃者が制御するコンテンツを被害者へのレスポンスに注入することができます。

HTTPパイプラインの非同期化

HTTP/1.1は、前のリクエストを待つことなく異なるリソースを要求することを許可します。したがって、中間にプロキシがある場合、プロキシのタスクはバックエンドに送信されたリクエストとそこからのレスポンスの同期を維持することです。

しかし、レスポンスキューを非同期化するには問題があります。攻撃者がHTTPレスポンススムージング攻撃を送信し、最初のリクエストとスムージングされたリクエストのレスポンスが即座に返されると、スムージングされたレスポンスは被害者のレスポンスキューに挿入されず、エラーとして単に破棄されます。

したがって、スムージングされたリクエストがバックエンドサーバー内で処理されるのに時間がかかる必要があります。そのため、スムージングされたリクエストが処理される頃には、攻撃者との通信は終了します。

この特定の状況で被害者がリクエストを送信し、スムージングされたリクエストが正当なリクエストの前に応答されると、スムージングされたレスポンスが被害者に送信されます。したがって、攻撃者は被害者によって「実行された」リクエストを制御します。

さらに、攻撃者がリクエストを実行し、被害者のリクエストに対する正当なレスポンスが攻撃者のリクエストの前に応答されると、被害者へのレスポンスが攻撃者に送信され、被害者へのレスポンスを「盗む」ことになります（例えば、Set-Cookieヘッダーを含むことがあります）。

複数のネストされたインジェクション

一般的なHTTPリクエストスムージングとのもう一つの興味深い違いは、一般的なスムージング攻撃では、目的は被害者のリクエストの先頭を変更して予期しないアクションを実行させることです。HTTPレスポンススムージング攻撃では、完全なリクエストを送信するため、1つのペイロードに数十のレスポンスを注入することができ、数十のユーザーを非同期化させることができます。

正当なユーザーに対して数十のエクスプロイトをより簡単に配布できるだけでなく、これはサーバーにDoSを引き起こすためにも使用できます。

エクスプロイトの組織

前述のように、この技術を悪用するには、サーバーに送信される最初のスムージングメッセージが処理されるのに多くの時間がかかる必要があります。

この時間のかかるリクエストは、被害者のレスポンスを盗むことを試みるだけで十分です。しかし、より複雑なエクスプロイトを実行したい場合、これはエクスプロイトの一般的な構造になります。

まず、HTTPリクエストスムージングを悪用する最初のリクエスト、次に時間のかかるリクエスト、そして1つ以上のペイロードリクエストがあり、そのレスポンスが被害者に送信されます。

HTTPレスポンスキューの非同期化を悪用する

他のユーザーのリクエストをキャプチャする

HTTPリクエストスムージングの既知のペイロードと同様に、被害者のリクエストを盗むことができますが、1つの重要な違いがあります：この場合、レスポンスに反映されるコンテンツを送信するだけで済み、永続的なストレージは必要ありません。

まず、攻撃者は反映されたパラメータを含む最終的なPOSTリクエストを含むペイロードを送信し、大きなContent-Lengthを指定します。

次に、最初のリクエスト（青）が処理され、スリーピーなリクエストが処理されている間（黄色）、被害者から到着する次のリクエストが反映されたパラメータの直後にキューに追加されます：

その後、被害者はスリーピーなリクエストのレスポンスを受け取り、その間に攻撃者が別のリクエストを送信した場合、反映されたコンテンツリクエストからのレスポンスが攻撃者に送信されます。

レスポンスの非同期化

ここまでで、HTTPリクエストスムージング攻撃を悪用して、クライアントが受け取るレスポンスを制御する方法と、被害者のために意図されたレスポンスを盗む方法を学びました。

しかし、レスポンスをさらに非同期化することも可能です。

HEADリクエストのような興味深いリクエストがあり、これはレスポンスボディ内にコンテンツを持たないことが指定されており、GETリクエストのようにContent-Lengthを含む必要があります。

したがって、攻撃者がHEADリクエストを注入すると、次のようになります：

その後、青いリクエストが攻撃者に応答されると、次の被害者のリクエストがキューに追加されます：

その後、被害者はHEADリクエストからのレスポンスを受け取り、これはContent-Lengthを含むがコンテンツは全く含まれないことになります。したがって、プロキシはこのレスポンスを被害者に送信せず、何らかのコンテンツを待つことになります。実際には、これは攻撃者によって注入された黄色のリクエストへのレスポンスになります：

コンテンツの混乱

前の例に従い、被害者が受け取るレスポンスのボディを制御できること、およびHEADレスポンスが通常そのヘッダーにContent-TypeとContent-Lengthを含むことを知っていると、次のようなリクエストを送信してXSSを引き起こすことができます。ページがXSSに対して脆弱でなくても：

キャッシュの汚染

前述のレスポンス非同期化コンテンツ混乱攻撃を悪用すると、キャッシュが被害者によって実行されたリクエストへのレスポンスを保存し、このレスポンスがXSSを引き起こす注入されたものであれば、キャッシュは汚染されます。

XSSペイロードを含む悪意のあるリクエスト：

キャッシュにレスポンスを保存するように指示するヘッダーを含む被害者への悪意のあるレスポンス：

ウェブキャッシュの欺瞞

この攻撃は前の攻撃に似ていますが、ペイロードをキャッシュ内に注入するのではなく、攻撃者が被害者の情報をキャッシュ内にキャッシュします：

レスポンスの分割

この攻撃の目的は、再びレスポンスの非同期化を悪用して、プロキシが100%攻撃者生成のレスポンスを送信させることです。

これを達成するために、攻撃者はレスポンス内にいくつかの値を反映しているウェブアプリケーションのエンドポイントを見つけ、HEADレスポンスのコンテンツ長を知る必要があります。

彼は次のようなエクスプロイトを送信します：

最初のリクエストが解決され、攻撃者に返されると、被害者のリクエストがキューに追加されます：

被害者は、**HEADレスポンス + 2番目のリクエストレスポンスのコンテンツ（反映されたデータの一部を含む）**をレスポンスとして受け取ります：

ただし、反映されたデータがHEADレスポンスのContent-Lengthに応じたサイズを持っていたため、レスポンスキュー内で有効なHTTPレスポンスを生成しました。

したがって、2番目の被害者の次のリクエストは、攻撃者によって完全に作成されたレスポンスを受け取ることになります。レスポンスが攻撃者によって完全に作成されているため、攻撃者はプロキシにレスポンスをキャッシュさせることもできます。