クロスサイト リクエスト フォージェリ (CSRF) は、Web アプリケーションで認証されたユーザーになりすまして不正なアクションを実行できる、Web セキュリティの脆弱性の一種です。CSRF 攻撃は、Web サイトがユーザーのブラウザーに対して持っている信頼を悪用し、ユーザーの知らないうちに、またはユーザーの同意なしに悪意のあるリクエストを行うように仕向けます。このタイプの攻撃は、Web アプリケーションの整合性とセキュリティに重大な脅威をもたらします。
クロスサイトリクエストフォージェリの起源とその最初の言及の歴史
「クロスサイト リクエスト フォージェリ」という用語は、2001 年に研究者 RSnake と Amit Klein が Web アプリケーションのセキュリティに関する議論の中で初めて作りました。ただし、CSRF のような攻撃の概念は 1990 年代半ばから知られていました。同様の攻撃に関する最初の言及は、1996 年に Adam Barth という研究者が、攻撃者が HTTP リクエストを偽造できる Netscape Navigator ブラウザの脆弱性について説明したときにさかのぼります。
クロスサイトリクエストフォージェリに関する詳細情報
CSRF 攻撃は、通常、アカウント設定の変更、購入、高い権限でのアクションの実行など、状態を変更するリクエストをターゲットとします。攻撃者は、特別に細工された URL またはフォームを含む悪意のある Web サイトまたはメールを作成し、ユーザーのブラウザーをトリガーして、ターゲットの Web アプリケーションで不正なアクションを実行します。これは、ブラウザーがユーザーの認証済みセッション資格情報を自動的に悪意のあるリクエストに含め、正当なリクエストのように見せかけるために発生します。
クロスサイトリクエストフォージェリの内部構造とその仕組み
CSRF の背後にあるメカニズムには、次の手順が含まれます。
- ユーザーは Web アプリケーションにログインし、通常は Cookie または非表示のフォーム フィールドに保存されている認証トークンを受け取ります。
- ユーザーがログインしたまま、悪意のある Web サイトにアクセスしたり、悪意のあるリンクをクリックしたりします。
- 悪意のある Web サイトは、ブラウザの Cookie またはセッション データに保存されているユーザーの資格情報を使用して、細工された HTTP リクエストを対象の Web アプリケーションに送信します。
- ターゲット Web アプリケーションはリクエストを受信し、そのリクエストにはユーザーの有効な認証トークンが含まれているため、正当なユーザーから送信されたものとしてリクエストを処理します。
- その結果、ユーザーが知らないうちに悪意のあるアクションがユーザーに代わって実行されます。
クロスサイトリクエストフォージェリの主な特徴の分析
CSRF 攻撃の主な特徴は次のとおりです。
- 目に見えない搾取: CSRF 攻撃は、ユーザーが気付かないうちに静かに実行される可能性があるため、危険であり、検出が困難です。
- ユーザーの信頼への依存: CSRF は、ユーザーのブラウザと Web アプリケーションの間に確立された信頼を悪用します。
- セッションベース: CSRF 攻撃は多くの場合、アクティブなユーザー セッションに依存し、ユーザーの認証状態を利用してリクエストを偽造します。
- 影響力のある行動: 攻撃は状態を変更する操作をターゲットにしており、データの変更や金銭的損失などの重大な結果をもたらします。
クロスサイトリクエストフォージェリの種類
| タイプ | 説明 |
|---|---|
| シンプルなCSRF | 最も一般的なタイプで、偽造された単一のリクエストが対象の Web アプリケーションに送信されます。 |
| ブラインドCSRF | 攻撃者は、応答を取得せずに細工したリクエストをターゲットに送信し、それを「ブラインド」にします。 |
| CSRF と XSS | 攻撃者は、CSRF とクロスサイト スクリプティング (XSS) を組み合わせて、被害者に対して悪意のあるスクリプトを実行します。 |
| JSONエンドポイントでのCSRF | 攻撃者は、JSON エンドポイントを使用するアプリケーションを標的とし、JSON データを操作して CSRF を実行します。 |
クロスサイトリクエストフォージェリの使用方法、問題点、解決策
悪用方法
- 不正なアカウント操作: 攻撃者はユーザーを騙してアカウント設定やパスワードを変更させる可能性があります。
- 金融取引: CSRF は不正な資金移動や購入を容易にする可能性があります。
- データ操作: 攻撃者はアプリケーション内のユーザーデータを変更または削除します。
解決策と予防
- CSRF トークン: 各リクエストに一意のトークンを実装して、その正当性を検証します。
- SameSite Cookie: SameSite 属性を使用して Cookie の範囲を制限します。
- カスタム リクエスト ヘッダー: リクエストを検証するためのカスタム ヘッダーを追加します。
- 二重送信 Cookie: トークン値に一致するセカンダリ Cookie を含めます。
主な特徴と類似用語との比較
| 学期 | 説明 |
|---|---|
| クロスサイトスクリプティング (XSS) | 他のユーザーが閲覧する Web ページに悪意のあるスクリプトを挿入することに重点を置いています。 |
| クロスサイトリクエストフォージェリ | 状態を変更するアクションをターゲットとし、ユーザーの信頼を利用して不正なリクエストを実行します。 |
| クロスサイトスクリプトのインクルード | 外部ドメインからの悪意のあるスクリプトを標的の Web アプリケーションに組み込みます。 |
Web テクノロジーが進化するにつれ、CSRF 攻撃に対抗するための新しい防御メカニズムが登場する可能性があります。生体認証、トークン化、多要素認証を統合することで、ユーザー認証を強化できます。さらに、ブラウザのセキュリティ強化と、CSRF の脆弱性を自動的に検出して防止するフレームワークは、将来の脅威を軽減する上で重要な役割を果たします。
プロキシサーバーがクロスサイトリクエストフォージェリとどのように関連するか
プロキシ サーバーは、ユーザーと Web アプリケーション間の仲介役として機能します。CSRF のコンテキストでは、プロキシ サーバーはユーザー リクエストの検証をさらに複雑にし、CSRF の脆弱性を軽減または悪化させる可能性があります。適切に構成されたプロキシ サーバーは、受信リクエストをフィルタリングおよび検証することでセキュリティをさらに強化し、CSRF 攻撃のリスクを軽減できます。
関連リンク
クロスサイト リクエスト フォージェリと Web アプリケーション セキュリティの詳細については、次のリソースを参照してください。
