mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-15 01:17:36 +00:00
111 lines
12 KiB
Markdown
111 lines
12 KiB
Markdown
# HTTP レスポンススムギリング / デシンク
|
||
|
||
<details>
|
||
|
||
<summary><strong>htARTE（HackTricks AWS Red Team Expert）</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>を通じてゼロからヒーローまでAWSハッキングを学ぶ</strong></a><strong>！</strong></summary>
|
||
|
||
HackTricks をサポートする他の方法:
|
||
|
||
* **HackTricks で企業を宣伝**したい場合や **HackTricks をPDFでダウンロード**したい場合は、[**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop) をチェック！
|
||
* [**公式PEASS＆HackTricksスワッグ**](https://peass.creator-spring.com)を入手
|
||
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family)を発見し、独占的な [**NFTs**](https://opensea.io/collection/the-peass-family) のコレクションを見つける
|
||
* **💬 [**Discordグループ**](https://discord.gg/hRep4RUj7f) に参加するか、[**telegramグループ**](https://t.me/peass) に参加するか、**Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live) をフォローする**。
|
||
* **ハッキングトリックを共有するために、** [**HackTricks**](https://github.com/carlospolop/hacktricks) と [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) のGitHubリポジトリにPRを提出する**。
|
||
|
||
</details>
|
||
|
||
**この記事の技術は、次のビデオから取得されました: [https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s](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 レスポンスキューデシンクロナイゼーションの悪用
|
||
|
||
### 他のユーザーのリクエストのキャプチャ <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
|
||
|
||
HTTP リクエストスムギリングの既知のペイロードと同様に、 **被害者のリクエストを盗む** ことができますが、重要な違いがあります: この場合、 **レスポンスに反映される送信コンテンツ** が必要であり、 **永続的なストレージ** は必要ありません。
|
||
|
||
まず、攻撃者は、最終的な POST リクエストを含むペイロードを送信し、末尾に反映されるパラメータと大きな Content-Length を含めます
|
||
|
||
次に、 **初期リクエスト**（青色）が **処理される間** に **眠たいリクエスト**（黄色）が処理されている間に、 **被害者から到着する次のリクエスト** が **反映されたパラメータの直後にキューに追加されます**:
|
||
|
||
その後、 **被害者** は **眠たい** リクエストの **レスポンスを受け取り**、その間に **攻撃者が別のリクエストを送信した場合**、 **反映されたコンテンツリクエストのレスポンスが攻撃者に送信されます**。
|
||
|
||
## レスポンスデシンクロナイゼーション
|
||
|
||
ここまでで、HTTP リクエストスムギリング攻撃を悪用して、 **クライアントが受け取るレスポンスのリクエストを制御** し、その後、 **被害者のために意図されていたレスポンスを盗む方法** を学びました。
|
||
|
||
しかし、 **さらにレスポンスをさらに非同期化することができます**。
|
||
|
||
**HEAD** リクエストのような興味深いリクエストがあり、 **レスポンスボディにコンテンツが含まれていない** ことが指定されており、 **GET リクエストのように Content-Length を含む必要がある** ことがあります。
|
||
|
||
したがって、攻撃者が次の画像のように **HEAD** リクエストを **注入** すると:
|
||
|
||
その後、 **青色のリクエストが攻撃者に返された後**、次の被害者のリクエストがキューに追加されます:
|
||
|
||
その後、 **被害者** は **HEAD** リクエストの **レスポンスを受け取ります**。これには **Content-Length が含まれていますが、コンテンツはまったく含まれていません**。したがって、プロキシはこのレスポンスを **被害者に送信せず、いくつかのコンテンツを待機** します。実際には、これは **攻撃者によって注入された黄色のリクエストのレスポンス** になります:
|
||
|
||
### コンテンツ混乱
|
||
|
||
前の例に続いて、被害者が受け取るレスポンスのボディを **制御** でき、 **HEAD** **レスポンス** には通常、 **Content-Type と Content-Length** がヘッダーに含まれていることを知っているので、次のようなリクエストを送信して、ページが XSS に脆弱でなくても被害者に **XSS を引き起こす** ことができます:
|
||
|
||
### キャッシュポイズニング
|
||
|
||
以前にコメントされたレスポンスデシンクロナイゼーションコンテンツ混乱攻撃を悪用すると、 **キャッシュが被害者によって実行されたリクエストのレスポンスを保存し、このレスポンスが XSS を引き起こす注入されたものである場合、キャッシュが毒されます**。
|
||
|
||
XSS ペイロードを含む悪意のあるリクエスト:
|
||
|
||
被害者に送信される悪意のあるレスポンスで、キャッシュにレスポンスを保存することを示すヘッダーが含まれています:
|
||
|
||
{% hint style="warning" %}
|
||
この場合、 **"被害者" が攻撃者である** 場合、 **悪意のあるレスポンスでキャッシュポイズニングを実行** できるため、 **攻撃者は悪意のあるレスポンスでキャッシュされる URL を制御** できます。
|
||
{% endhint %}
|
||
|
||
### Web キャッシュ欺瞞
|
||
|
||
この攻撃は前の攻撃と似ていますが、 **キャッシュ内にペイロードを注入する代わりに、攻撃者はキャッシュ内に被害者情報をキャッシュすることになります**:
|
||
|
||
### レスポンス分割
|
||
|
||
この攻撃の目的は、再び **レスポンスデシンクロナイゼーションを悪用** して、 **プロキシが 100% 攻撃者が生成したレスポンスを送信するようにする** ことです。
|
||
|
||
これを達成するために、攻撃者は、 **レスポンス内にいくつかの値を反映** し、 **HEAD レスポンスの Content-Length を知っている** ウェブアプリケーションのエンドポイントを見つける必要があります。
|
||
|
||
彼は次のような **エクスプロイト** を送信します:
|
||
|
||
最初のリクエストが解決され、攻撃者に返された後、 **被害者のリクエストがキューに追加されます**:
|
||
|
||
被害者は **HEAD レスポンス + 2 番目のリクエストのレスポンスの内容（反映されたデータの一部を含む）** を受け取ります:
|
||
|
||
ただし、 **反映されたデータが HEAD レスポンスの Content-Length に応じたサイズを持っていた** ことに注意してください。これにより、 **2 番目の被害者の次のリクエスト** は、 **攻撃者によって完全に作成されたレスポンスを受け取る** ことになります。レスポンスが攻撃者によって完全に作成されたため、 **プロキシがレスポンスをキャッシュ** することもできます。
|