# CSRF (クロスサイトリクエストフォージェリ) {% 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 %}
[**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy)サーバーに参加して、経験豊富なハッカーやバグバウンティハンターとコミュニケーションを取りましょう! **ハッキングの洞察**\ ハッキングのスリルと課題に深く掘り下げたコンテンツに参加しましょう **リアルタイムハックニュース**\ リアルタイムのニュースと洞察を通じて、急速に変化するハッキングの世界に遅れずについていきましょう **最新の発表**\ 新しいバグバウンティの開始や重要なプラットフォームの更新について情報を得ましょう **[**Discord**](https://discord.com/invite/N3FrSbmwdy)に参加して、今日からトップハッカーとコラボレーションを始めましょう!** ## クロスサイトリクエストフォージェリ (CSRF) の説明 **クロスサイトリクエストフォージェリ (CSRF)** は、ウェブアプリケーションに見られるセキュリティ脆弱性の一種です。これにより、攻撃者は認証されたセッションを悪用して、無防備なユーザーの代わりにアクションを実行できます。攻撃は、被害者のプラットフォームにログインしているユーザーが悪意のあるサイトを訪れたときに実行されます。このサイトは、JavaScriptの実行、フォームの送信、または画像の取得などの方法で、被害者のアカウントへのリクエストをトリガーします。 ### CSRF攻撃の前提条件 CSRF脆弱性を悪用するには、いくつかの条件を満たす必要があります: 1. **価値のあるアクションを特定する**:攻撃者は、ユーザーのパスワード、メールアドレスの変更、または権限の昇格など、悪用する価値のあるアクションを見つける必要があります。 2. **セッション管理**:ユーザーのセッションは、クッキーまたはHTTP基本認証ヘッダーのみで管理されるべきです。他のヘッダーはこの目的のために操作できません。 3. **予測不可能なパラメータの不在**:リクエストには予測不可能なパラメータが含まれていない必要があります。これらは攻撃を防ぐ可能性があります。 ### クイックチェック **Burpでリクエストをキャプチャ**し、CSRF保護を確認することができます。また、ブラウザからテストするには、**Copy as fetch**をクリックしてリクエストを確認できます:
### CSRFからの防御 CSRF攻撃から保護するために実装できるいくつかの対策があります: * [**SameSiteクッキー**](hacking-with-cookies/#samesite):この属性は、ブラウザがクロスサイトリクエストと共にクッキーを送信するのを防ぎます。[SameSiteクッキーの詳細](hacking-with-cookies/#samesite)。 * [**クロスオリジンリソースシェアリング**](cors-bypass.md):被害者サイトのCORSポリシーは、攻撃の実行可能性に影響を与える可能性があります。特に、攻撃が被害者サイトからの応答を読み取る必要がある場合。[CORSバイパスについて学ぶ](cors-bypass.md)。 * **ユーザー確認**:ユーザーのパスワードを求めたり、キャプチャを解決させたりすることで、ユーザーの意図を確認できます。 * **リファラーまたはオリジンヘッダーの確認**:これらのヘッダーを検証することで、リクエストが信頼できるソースから来ていることを確認できます。ただし、URLを慎重に作成することで、実装が不十分なチェックを回避できる場合があります。例えば: * `http://mal.net?orig=http://example.com`を使用する(URLが信頼できるURLで終わる) * `http://example.com.mal.net`を使用する(URLが信頼できるURLで始まる) * **パラメータ名の変更**:POSTまたはGETリクエストのパラメータ名を変更することで、自動化された攻撃を防ぐのに役立ちます。 * **CSRFトークン**:各セッションにユニークなCSRFトークンを組み込み、以降のリクエストでこのトークンを要求することで、CSRFのリスクを大幅に軽減できます。トークンの効果は、CORSを強制することで向上させることができます。 これらの防御を理解し、実装することは、ウェブアプリケーションのセキュリティと整合性を維持するために重要です。 ## 防御のバイパス ### POSTからGETへ 悪用したいフォームが**CSRFトークンを持つPOSTリクエストを送信するように準備されている**かもしれませんが、**GET**も**有効**であり、GETリクエストを送信したときに**CSRFトークンがまだ検証されているか**を**確認**する必要があります。 ### トークンの欠如 アプリケーションは、トークンが存在する場合に**トークンを検証するメカニズム**を実装しているかもしれません。しかし、トークンが存在しない場合に検証が完全にスキップされると、脆弱性が生じます。攻撃者は、トークンを運ぶパラメータを**削除すること**によってこれを悪用できます。これにより、検証プロセスを回避し、クロスサイトリクエストフォージェリ (CSRF) 攻撃を効果的に実行できます。 ### CSRFトークンがユーザーセッションに結びついていない アプリケーションが**CSRFトークンをユーザーセッションに結びつけていない**場合、重大な**セキュリティリスク**が存在します。これらのシステムは、各トークンが開始セッションにバインドされていることを確認するのではなく、**グローバルプール**に対してトークンを検証します。 攻撃者がこれを悪用する方法は次のとおりです: 1. **自分のアカウントを使用して認証**します。 2. **グローバルプールから有効なCSRFトークンを取得**します。 3. **このトークンを使用して**、被害者に対するCSRF攻撃を行います。 この脆弱性により、攻撃者は被害者の代わりに無許可のリクエストを行うことができ、アプリケーションの**不十分なトークン検証メカニズム**を悪用します。 ### メソッドバイパス リクエストが「**奇妙な**」**メソッド**を使用している場合、**メソッド**の**オーバーライド機能**が機能しているか確認してください。例えば、**PUT**メソッドを使用している場合、**POST**メソッドを使用して**送信**することを試みることができます:_https://example.com/my/dear/api/val/num?**\_method=PUT**_ これは、**POSTリクエスト内に\_methodパラメータを送信する**か、**ヘッダー**を使用することでも機能します: * _X-HTTP-Method_ * _X-HTTP-Method-Override_ * _X-Method-Override_ ### カスタムヘッダートークンのバイパス リクエストが**CSRF保護メソッド**として**トークン**を持つ**カスタムヘッダー**を追加している場合: * **カスタマイズされたトークンとヘッダーなしでリクエストをテスト**します。 * **同じ長さだが異なるトークンでリクエストをテスト**します。 ### CSRFトークンがクッキーによって検証される アプリケーションは、トークンをクッキーとリクエストパラメータの両方に複製することによってCSRF保護を実装するか、CSRFクッキーを設定し、バックエンドで送信されたトークンがクッキーに対応しているかを検証することがあります。アプリケーションは、リクエストパラメータ内のトークンがクッキーの値と一致するかどうかを確認することでリクエストを検証します。 ただし、この方法は、攻撃者が被害者のブラウザにCSRFクッキーを設定できる脆弱性がある場合、CSRF攻撃に対して脆弱です。攻撃者は、クッキーを設定する欺瞞的な画像を読み込んだ後、CSRF攻撃を開始することでこれを悪用できます。 以下は、攻撃がどのように構成されるかの例です: ```html
``` {% hint style="info" %} 注意してください、**csrfトークンがセッションクッキーに関連している場合、この攻撃は機能しません**。なぜなら、あなたは被害者のセッションを設定する必要があり、そのため自分自身を攻撃することになります。 {% endhint %} ### Content-Typeの変更 [**こちら**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests)によると、**プレフライト**リクエストを避けるために**POST**メソッドを使用する場合、許可されているContent-Typeの値は次の通りです: * **`application/x-www-form-urlencoded`** * **`multipart/form-data`** * **`text/plain`** ただし、使用される**Content-Type**によって**サーバーのロジックが異なる場合がある**ため、上記の値や**`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._などの他の値も試すべきです。 例([こちら](https://brycec.me/posts/corctf\_2021\_challenges)から)として、JSONデータをtext/plainとして送信する方法: ```html
``` ### JSONデータのためのプリフライトリクエストのバイパス POSTリクエストを介してJSONデータを送信しようとする際、HTMLフォームで`Content-Type: application/json`を使用することは直接的には不可能です。同様に、`XMLHttpRequest`を使用してこのコンテンツタイプを送信すると、プリフライトリクエストが開始されます。それでも、この制限を回避し、サーバーがContent-Typeに関係なくJSONデータを処理するかどうかを確認するための戦略があります: 1. **代替コンテンツタイプの使用**: フォームで`enctype="text/plain"`を設定することにより、`Content-Type: text/plain`または`Content-Type: application/x-www-form-urlencoded`を使用します。このアプローチは、バックエンドがContent-Typeに関係なくデータを利用するかどうかをテストします。 2. **コンテンツタイプの変更**: サーバーがコンテンツをJSONとして認識することを保証しつつプリフライトリクエストを回避するために、`Content-Type: text/plain; application/json`でデータを送信できます。これはプリフライトリクエストをトリガーしませんが、サーバーが`application/json`を受け入れるように設定されていれば正しく処理される可能性があります。 3. **SWFフラッシュファイルの利用**: あまり一般的ではありませんが、SWFフラッシュファイルを使用してこのような制限を回避する方法もあります。この技術の詳細については、[この投稿](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937)を参照してください。 ### リファラー / オリジンチェックのバイパス **リファラーヘッダーを避ける** アプリケーションは、'Referer'ヘッダーが存在する場合のみ検証することがあります。このヘッダーをブラウザが送信しないようにするために、次のHTMLメタタグを使用できます: ```xml ``` これにより、'Referer' ヘッダーが省略され、一部のアプリケーションでの検証チェックを回避する可能性があります。 **Regexp バイパス** {% content-ref url="ssrf-server-side-request-forgery/url-format-bypass.md" %} [url-format-bypass.md](ssrf-server-side-request-forgery/url-format-bypass.md) {% endcontent-ref %} Referrer がパラメータ内で送信する URL のサーバーのドメイン名を設定するには、次のようにします: ```html
``` ### **HEADメソッドバイパス** [**このCTFの解説**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution)の最初の部分では、[Oakのソースコード](https://github.com/oakserver/oak/blob/main/router.ts#L281)が説明されており、ルーターは**HEADリクエストをGETリクエストとして処理する**ように設定されています - これはOakに特有の一般的な回避策です。HEADリクエストを処理する特定のハンドラーの代わりに、単に**GETハンドラーに渡されますが、アプリはレスポンスボディを削除します**。 したがって、GETリクエストが制限されている場合は、**GETリクエストとして処理されるHEADリクエストを送信することができます**。 ## **エクスプロイトの例** ### **CSRFトークンの抽出** **CSRFトークン**が**防御**として使用されている場合、[**XSS**](xss-cross-site-scripting/#xss-stealing-csrf-tokens)脆弱性や[**ダングリングマークアップ**](dangling-markup-html-scriptless-injection/)脆弱性を悪用して**抽出を試みる**ことができます。 ### **HTMLタグを使用したGET** ```xml

404 - Page not found

The URL you are requesting is no longer available ``` 他のHTML5タグで自動的にGETリクエストを送信できるものは次のとおりです: ```html