HTTP Response Smuggling / Desync
この記事の技術は、次のビデオから取得されました: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s
HTTP リクエストキューデシンクロナイゼーション
まず、この技術は HTTP リクエストスムギリングの脆弱性を悪用 するため、それが何かを知る必要があります:
この技術と一般的な HTTP リクエストスムギリングの 主な違い は、 被害者のリクエストに接頭辞を追加して攻撃する代わりに、 被害者が受け取るレスポンスを漏洩または変更する ことです。これは、HTTP リクエストスムギリングを悪用するために 1 つのリクエストと半分を送信する代わりに、 2 つの完全なリクエストを送信してプロキシのレスポンスキューを非同期化する ことができるためです。
これは、 レスポンスキューを非同期化 することができるため、 被害者の正当なリクエストからのレスポンスが攻撃者に送信される か、 被害者に対して攻撃者が制御可能なコンテンツをレスポンスに注入する ことができるからです。
HTTP パイプラインデシンク
HTTP/1.1 では、 前のリソースを待つ必要がない で 異なるリソースを要求 することができます。したがって、 途中にプロキシがある場合、バックエンドに送信されたリクエストとそのレスポンスの 同期された一臀を維持する のはプロキシの役割です。
しかし、レスポンスキューを非同期化する問題があります。攻撃者が HTTP レスポンススムギリング攻撃を送信し、 初期リクエストとスムギリングされたリクエストへのレスポンスが直ちに返される場合、スムギリングされたレスポンスは 被害者のレスポンスキューに挿入されず、エラーとして破棄されるだけ です。
したがって、 スムギリングされたリクエストがバックエンドサーバーで処理されるのに時間がかかる必要があります。そのため、スムギリングされたリクエストが処理される時点で、攻撃者との通信は終了します。
特定の状況で 被害者がリクエストを送信 し、 スムギリングされたリクエストが正当なリクエストよりも先に応答される場合、 スムギリングされたレスポンスが被害者に送信されます。したがって、攻撃者は 被害者が"実行した"リクエストを制御 します。
さらに、 攻撃者がリクエストを実行 し、 被害者のリクエストに対する正当なレスポンスが攻撃者のリクエストよりも 前に応答される場合、 被害者へのレスポンスが攻撃者に送信され、被害者へのレスポンス（たとえばヘッダー Set-Cookie を含むことができる）が 盗まれます。
複数のネストされたインジェクション
一般的な HTTP リクエストスムギリング との 興味深い違い は、一般的なスムギリング攻撃では、 被害者のリクエストの先頭を変更 して予期しないアクションを実行することが目的です。 HTTP レスポンススムギリング攻撃 では、 完全なリクエストを送信 するため、 1 つのペイロードに複数のレスポンスをインジェクト して、 複数のユーザーを非同期化 し、 インジェクトされたレスポンスを受信する ユーザーを 複数に分散 することができます。
合法的なユーザーに 複数のエクスプロイトをより簡単に配布 することができるだけでなく、サーバーで DoS を引き起こすためにも使用できます。
エクスプロイトの組織化
前述のように、この技術を悪用するには、 サーバーに最初のスムギリングメッセージ が 処理されるのに多くの時間がかかる必要があります。
この 時間のかかるリクエストは、被害者のレスポンスを盗もうとする場合には十分 です。しかし、より複雑なエクスプロイトを実行したい場合は、エクスプロイトのための一般的な構造になります。
まず、 HTTP リクエストスムギリングを悪用する初期 リクエスト、次に 時間のかかるリクエスト、そして 被害者に送信される レスポンスの 1つ以上のペイロードリクエスト。
HTTP レスポンスキューデシンクロナイゼーションの悪用
他のユーザーのリクエストをキャプチャする
HTTP リクエストスムギリングの既知のペイロードと同様に、 被害者のリクエストを盗む ことができますが、重要な違いがあります: この場合、 レスポンスに反映される送信コンテンツ が必要であり、 永続的なストレージは不要 です。
まず、攻撃者は、 最終的な POST リクエストに反映されたパラメータを含むペイロード と大きな Content-Length を含むペイロードを送信します
次に、 初期リクエスト（青）が 処理された後、 スリーピー リクエストが処理されている間（黄色）、 被害者から到着する次のリクエスト が 反映されたパラメータの直後にキューに追加されます:
その後、 被害者 は スリーピー リクエストの レスポンスを受け取り、その間に 攻撃者が別のリクエストを送信した場合、 反映されたコンテンツリクエストのレスポンスが攻撃者に送信されます。
レスポンスデシンクロナイゼーション
これまでに、HTTP リクエストスムギリング攻撃を悪用して、 クライアントが受信するリクエスト のレスポンスを制御 する方法と、その後 被害者向けに意図されていたレスポンスを盗む 方法を学びました。
しかし、 さらに レスポンスを さらに非同期化することができます。
GET リクエストのように、 レスポンスボディにコンテンツが含まれていない と指定されている HEAD リクエストなどの興味深いリクエストがあり、 GET リクエストのように Content-Length を含む必要がある はずです。
したがって、攻撃者が HEAD リクエストを インジェクト すると、次の画像のようになります:
その後、 青色のリクエストが攻撃者に応答された後、次の被害者のリクエストがキューに挿入されます:
その後、 被害者 は HEAD リクエストの レスポンスを受け取ります が、 コンテンツは含まれていません。したがって、プロキシはこのレスポンスを 被害者に送信せず、いくつかのコンテンツを待機 しますが、実際には 攻撃者によって挿入された黄色のリクエストへのレスポンス になります:
内容の混乱
前の例に続いて、被害者が受け取るレスポンスのボディを制御できることを知っていると、HEAD レスポンスは通常、そのヘッダにContent-TypeとContent-Lengthを含んでいるため、次のようなリクエストを送信することで、ページがXSSに脆弱でなくても被害者にXSSを引き起こすことができます：
キャッシュの汚染
以前にコメントされたレスポンスの非同期化Content Confusion攻撃を悪用すると、キャッシュが被害者によって実行されたリクエストへのレスポンスを保存し、このレスポンスがXSSを引き起こすような注入されたものである場合、キャッシュが汚染されます。
XSSペイロードを含む悪意のあるリクエスト：
キャッシュにレスポンスを保存するように示すヘッダを含む被害者への悪意のあるレスポンス：
この場合、「被害者」が攻撃者である場合、悪意のあるレスポンスでキャッシュの汚染を任意のURLで実行できるようになります。攻撃者は悪意のあるレスポンスでキャッシュされるURLを制御できるため、注意してください。
Webキャッシュ欺瞞
この攻撃は前の攻撃と似ていますが、キャッシュ内にペイロードを注入する代わりに、攻撃者はキャッシュ内に被害者情報をキャッシュすることになります：
レスポンス分割
この攻撃の目的は、再びレスポンスの非同期化を悪用して、プロキシが100%攻撃者が生成したレスポンスを送信するようにすることです。
これを達成するために、攻撃者は、レスポンス内にいくつかの値を反映させるWebアプリケーションのエンドポイントを見つけ、HEADレスポンスのコンテンツ長を知る必要があります。
彼は次のようなエクスプロイトを送信します：
最初のリクエストが解決され、攻撃者に送り返された後、被害者のリクエストがキューに追加されます：
被害者は、**HEADレスポンス + 2番目のリクエストのレスポンスの内容（反映されたデータの一部を含む）**を受け取ります：
ただし、反映されたデータがHEADレスポンスのContent-Lengthに応じたサイズを持っていたことに注意してください。これにより、レスポンスキュー内で有効なHTTPレスポンスを生成するHEADレスポンスが生成されます。
したがって、2番目の被害者の次のリクエストは、攻撃者によって完全に作成されたレスポンスを受け取ることになります。攻撃者が完全に作成したレスポンスであるため、彼はまたプロキシがレスポンスをキャッシュすることができます。
Last updated
