# HTTP Response Smuggling / Desync
{% hint style="success" %}
AWSハッキングを学び、実践する:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\
GCPハッキングを学び、実践する: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
HackTricksをサポートする
* [**サブスクリプションプラン**](https://github.com/sponsors/carlospolop)を確認してください!
* **💬 [**Discordグループ**](https://discord.gg/hRep4RUj7f)または[**Telegramグループ**](https://t.me/peass)に参加するか、**Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**をフォローしてください。**
* **[**HackTricks**](https://github.com/carlospolop/hacktricks)および[**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud)のGitHubリポジトリにPRを送信してハッキングトリックを共有してください。**
{% endhint %}
**この投稿の技術は次のビデオから取得されました:** [**https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s**](https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s)
## HTTPリクエストキューの非同期化
まず、この技術は**HTTPリクエストスムーグリングの脆弱性を悪用します**ので、それが何であるかを知っておく必要があります:
この技術と一般的なHTTPリクエストスムーグリングの**主な違い**は、**攻撃する**のではなく、**被害者のリクエストにプレフィックスを追加する**のではなく、**被害者が受け取るレスポンスを漏洩または変更する**ことです。これは、HTTPリクエストスムーグリングを悪用するために1.5リクエストを送信する代わりに、**プロキシのレスポンスキューを非同期化するために2つの完全なリクエストを送信します**。
これは、**レスポンスキューを非同期化することができるため**、**被害者の正当なリクエストからのレスポンスが攻撃者に送信される**か、**攻撃者が制御するコンテンツを被害者へのレスポンスに注入する**ことができます。
### HTTPパイプラインの非同期化
HTTP/1.1は、**以前のリクエストを待つことなく異なるリソースを要求する**ことを許可します。したがって、**中間にプロキシがある場合**、プロキシのタスクは**バックエンドに送信されたリクエストとそこからのレスポンスの同期を維持する**ことです。
しかし、レスポンスキューを非同期化するには問題があります。攻撃者がHTTPレスポンススムーグリング攻撃を送信し、**最初のリクエストとスムーグリングされたリクエストへのレスポンスが即座に返される**と、スムーグリングされたレスポンスは被害者のレスポンスキューに挿入されず、**単にエラーとして破棄されます**。
![](<../.gitbook/assets/image (633).png>)
したがって、**スムーグリングされたリクエストがバックエンドサーバー内で処理されるのに時間がかかる必要があります**。そのため、スムーグリングされたリクエストが処理される頃には、攻撃者との通信は終了します。
この特定の状況で**被害者がリクエストを送信し、スムーグリングされたリクエストが正当なリクエストの前に応答される**と、**スムーグリングされたレスポンスが被害者に送信されます**。したがって、攻撃者は**被害者によって「実行された」リクエストを制御します**。
さらに、**攻撃者がリクエストを実行し、被害者のリクエストに対する正当なレスポンスが攻撃者のリクエストの前に**返されると、**被害者へのレスポンスが攻撃者に送信されます**。これにより、被害者へのレスポンスを**盗む**ことになります(例えば、**Set-Cookie**ヘッダーを含むことがあります)。
![](<../.gitbook/assets/image (1020).png>)
![](<../.gitbook/assets/image (719).png>)
### 複数のネストされたインジェクション
一般的な**HTTPリクエストスムーグリング**とのもう一つの**興味深い違い**は、一般的なスムーグリング攻撃では、**目的**が**被害者のリクエストの先頭を変更して予期しないアクションを実行させる**ことです。**HTTPレスポンススムーグリング攻撃**では、**完全なリクエストを送信しているため**、**1つのペイロードに数十のレスポンスを注入する**ことができ、**数十のユーザーを非同期化させる**ことができます。
正当なユーザーに対して**数十のエクスプロイトをより簡単に配布できる**だけでなく、これはサーバーに**DoS**を引き起こすためにも使用できます。
### エクスプロイトの組織
前述のように、この技術を悪用するには、**サーバーに送信される最初のスムーグリングメッセージが処理されるのに多くの時間がかかる必要があります**。
この**時間のかかるリクエストは**、**被害者のレスポンスを盗むことを試みるだけであれば十分です**。しかし、より複雑なエクスプロイトを実行したい場合、これはエクスプロイトの一般的な構造になります。
まず、**HTTPリクエストスムーグリングを悪用する初期リクエスト**、次に**時間のかかるリクエスト**、そして**1つ以上のペイロードリクエスト**があり、そのレスポンスが被害者に送信されます。
## HTTPレスポンスキューの非同期化を悪用する
### 他のユーザーのリクエストをキャプチャする
HTTPリクエストスムーグリングの既知のペイロードと同様に、**被害者のリクエストを盗む**ことができますが、1つの重要な違いがあります:この場合、**レスポンスに反映されるコンテンツを送信するだけで済み、**永続的なストレージは必要ありません**。
まず、攻撃者は**反映されたパラメータ**を末尾に持つ**最終POSTリクエストを含むペイロード**を送信し、大きなContent-Lengthを指定します。
![](<../.gitbook/assets/image (1053).png>)
次に、**最初のリクエスト**(青)が**処理され**、**スリープ中の**リクエストが処理されている間(黄色)、**被害者から到着する次のリクエスト**が**反映されたパラメータの直後にキューに追加されます**:
![](<../.gitbook/assets/image (794).png>)
その後、**被害者**は**スリープ中の**リクエストに対する**レスポンスを受け取り、もしその間に**攻撃者が別のリクエストを送信した場合**、**反映されたコンテンツリクエストからのレスポンスが攻撃者に送信されます**。
## レスポンスの非同期化
ここまでで、HTTPリクエストスムーグリング攻撃を悪用して、**クライアントが受け取るレスポンスを制御する**方法と、**被害者のために意図されたレスポンスを盗む**方法を学びました。
しかし、レスポンスを**さらに非同期化する**ことも可能です。
**HEAD**リクエストのような興味深いリクエストがあり、これは**レスポンスボディ内にコンテンツを持たないことが指定されており**、**GETリクエストのようにContent-Lengthを含む必要があります**。
したがって、攻撃者が**HEAD**リクエストを**注入すると**、次のようになります:
![](<../.gitbook/assets/image (1107).png>)
その後、**青いリクエストが攻撃者に応答されると**、次の被害者のリクエストがキューに追加されます:
![](<../.gitbook/assets/image (999).png>)
その後、**被害者**は**HEAD**リクエストからの**レスポンスを受け取りますが、これは**Content-Lengthを含むがコンテンツは全く含まれない**ものになります。したがって、プロキシは**このレスポンスを被害者に送信せず、**何らかの**コンテンツ**を待つことになります。実際には、これは**攻撃者によって注入された黄色のリクエストへのレスポンス**になります:
![](<../.gitbook/assets/image (735).png>)
### コンテンツの混乱
前の例に従い、**被害者が受け取るレスポンスのボディを制御できること**、および**HEAD**レスポンスが通常そのヘッダーに**Content-TypeとContent-Length**を含むことを知っていると、次のようなリクエストを送信して**XSSを引き起こす**ことができます。ページがXSSに対して脆弱でなくても:
![](<../.gitbook/assets/image (688).png>)
### キャッシュポイズニング
前述のレスポンス非同期化コンテンツ混乱攻撃を悪用すると、**キャッシュが被害者によって実行されたリクエストへのレスポンスを保存し、このレスポンスがXSSを引き起こす注入されたものであれば、キャッシュがポイズンされます**。
XSSペイロードを含む悪意のあるリクエスト:
![](<../.gitbook/assets/image (614).png>)
被害者に対する悪意のあるレスポンスで、キャッシュにレスポンスを保存するよう指示するヘッダーを含む:
![](<../.gitbook/assets/image (566).png>)
{% hint style="warning" %}
この場合、**「被害者」が攻撃者である場合、攻撃者は今や**任意のURLでキャッシュポイズニングを実行できる**。なぜなら、悪意のあるレスポンスでキャッシュされるURLを**制御できるからです**。
{% endhint %}
### ウェブキャッシュの欺瞞
この攻撃は前の攻撃に似ていますが、**キャッシュ内にペイロードを注入するのではなく、攻撃者が被害者の情報をキャッシュ内に保存します**:
![](<../.gitbook/assets/image (991).png>)
### レスポンス分割
この攻撃の**目的**は、再び**レスポンスの非同期化**を悪用して、**プロキシが100%攻撃者生成のレスポンスを送信させる**ことです。
これを達成するために、攻撃者は**レスポンス内にいくつかの値を反映する**ウェブアプリケーションのエンドポイントを見つけ、**HEADレスポンスのコンテンツ長を知る必要があります**。
攻撃者は次のような**エクスプロイト**を送信します:
![](<../.gitbook/assets/image (911).png>)
最初のリクエストが解決され、攻撃者に返されると、**被害者のリクエストがキューに追加されます**:
![](<../.gitbook/assets/image (737).png>)
被害者は**HEADレスポンス + 2番目のリクエストレスポンスのコンテンツ(反映されたデータの一部を含む)**をレスポンスとして受け取ります:
![](<../.gitbook/assets/image (356).png>)
ただし、**反映されたデータがHEADレスポンスのContent-Lengthに応じたサイズを持っていたため、レスポンスキュー内で有効なHTTPレスポンスを生成しました**。
したがって、**2番目の被害者の次のリクエストは、**攻撃者によって完全に作成されたものを**レスポンスとして受け取ります**。レスポンスが攻撃者によって完全に作成されているため、攻撃者は**プロキシにレスポンスをキャッシュさせることもできます**。
{% hint style="success" %}
AWSハッキングを学び、実践する:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\
GCPハッキングを学び、実践する: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
HackTricksをサポートする
* [**サブスクリプションプラン**](https://github.com/sponsors/carlospolop)を確認してください!
* **💬 [**Discordグループ**](https://discord.gg/hRep4RUj7f)または[**Telegramグループ**](https://t.me/peass)に参加するか、**Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**をフォローしてください。**
* **[**HackTricks**](https://github.com/carlospolop/hacktricks)および[**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud)のGitHubリポジトリにPRを送信してハッキングトリックを共有してください。**
{% endhint %}