IT用語集 2023/10/16

クロスサイトリクエストフォージェリ（CSRF）とは？わかりやすく10分で解説

コラム

CSRF（Cross-Site Request Forgery：クロスサイトリクエストフォージェリ）は、ログイン中のユーザーのブラウザに、本人が意図しないリクエストを送信させる攻撃です。攻撃者がパスワードを直接盗まなくても、ブラウザが保持しているCookieやセッションを利用して、メールアドレス変更、送金、購入、権限変更などの操作が実行される可能性があります。Webサービス側は、ログイン済みかどうかだけでなく、その操作が本人の意思で送信されたかを検証する設計が必要です。

CSRF攻撃とは

CSRF攻撃とは、ユーザーが認証済みのWebサービスに対して、第三者サイトやメールなどを経由して意図しないリクエストを送信させる攻撃です。ユーザーが対象サイトにログインしている状態で攻撃者のページを開くと、ブラウザがCookieを付けて対象サイトへリクエストを送る場合があります。サーバ側がCookieによるログイン判定だけで処理を進めると、本人の操作として扱ってしまう可能性があります。

CSRFで狙われるのは、情報閲覧よりも状態変更を伴う操作です。メールアドレス変更、パスワード変更、送金、購入、配送先住所の変更、APIキーの再発行、ユーザー招待、権限変更などが代表例です。管理者権限を持つアカウントが狙われると、影響は個人アカウントだけでなく組織全体に及びます。

CSRF攻撃の基本

Webサービスでは、利用者の利便性を高めるため、ログイン状態をCookieやセッションで維持します。この仕組みにより、ユーザーはページを移動するたびに再ログインせずに済みます。一方で、状態変更リクエストの正当性を十分に検証していない場合、攻撃者のページから送られたリクエストでも、ログイン済みユーザーの操作として処理されるリスクがあります。

CSRFが成立する条件

CSRFは、どのWebサービスでも常に成立するわけではありません。典型的には、次の条件が重なったときにリスクが高まります。

ユーザーが対象サイトにログイン済みで、セッションが有効である
状態変更を伴う処理が、Cookieによるログイン判定だけで実行できる
CSRFトークン、Origin検証、SameSite属性などの対策が不十分である
送金、購入、設定変更、権限変更などの操作が追加確認なしで完了する

攻撃者は、ユーザーのパスワードを知らなくても、ブラウザが自動的に送るCookieを利用できます。サーバ側が「ログイン済みユーザーから届いたリクエスト」と「本人の意思で送信されたリクエスト」を区別できない設計では、CSRFの影響を受けやすくなります。

CSRFの動作メカニズム

一般的なCSRFの流れは、次のように整理できます。

ユーザーが正規サイトにログインし、ブラウザにセッションCookieが保存される
ユーザーが攻撃者の用意したページやメール内リンクを開く
攻撃者のページが、画像読み込み、自動送信フォーム、スクリプトなどで正規サイトへリクエストを送る
ブラウザがCookieの送信条件を満たす場合、正規サイト宛のリクエストにCookieを付与する
正規サイトが本人の意思を確認しないまま処理を実行する

この攻撃では、ユーザーが正規サイトの操作画面を開いていなくても、背後でリクエストが送信される可能性があります。そのため、サービス提供側は「ログイン済みであること」と「その操作を本人が意図していること」を分けて検証する必要があります。

CSRFが危険な理由

CSRFの危険性は、利用者が攻撃に気づきにくい点にあります。ユーザーは罠ページを開いただけで、正規サイト上では送金、設定変更、購入、権限付与などが完了している場合があります。処理結果の通知や履歴確認が弱いサービスでは、被害発見が遅れます。

また、CSRFは単独で使われるだけではありません。クロスサイトスクリプティング（XSS）と組み合わされると、CSRFトークンの窃取や画面上の操作誘導が可能になり、被害が拡大しやすくなります。CSRF対策は、XSS対策、認証設計、権限管理、ログ監視とあわせて検討します。

CSRF攻撃の具体例

CSRFの対策を考えるには、どの操作が狙われるかを具体的に把握する必要があります。特に、ワンクリックや自動送信で状態変更が完了する機能は注意が必要です。

ショッピングサイトでの不正操作

オンラインショッピングサイトでは、ログイン中のユーザーに対して、カート追加、配送先変更、注文確定、決済設定変更などのリクエストを送らせる攻撃が想定されます。状態変更がGETリクエストで実行できる設計や、確認画面なしで注文が完了する設計では、CSRFの影響が大きくなります。

購入や送金のように金銭が関係する処理では、CSRFトークンに加え、再認証、確認画面、通知、取引ログの確認を組み合わせます。リクエストを受け付けるだけでなく、利用者が気づける仕組みも被害抑制に役立ちます。

アカウント設定の変更

メールアドレス変更、パスワード変更、二要素認証の無効化、バックアップメールの追加、外部アプリ連携の許可なども狙われます。これらの操作が不正に実行されると、攻撃者がアカウントを支配しやすくなります。

認証設定や連絡先情報の変更では、現在のパスワード入力、再認証、確認メール、変更通知、一定時間の反映保留などを組み合わせると、CSRFだけで完了するリスクを下げられます。

権限・APIキー・管理機能の悪用

管理画面や業務SaaSでは、ユーザー招待、管理者権限の付与、APIキー発行、Webhook設定変更、外部連携の追加が被害につながります。管理者がログインした状態で罠ページを開くと、攻撃者に高い権限が渡る可能性があります。

管理機能では、CSRFトークンだけでなく、操作ごとの権限確認、再認証、承認フロー、監査ログ、通知を組み合わせます。APIキー発行や権限変更のような操作は、通常のプロフィール更新よりも厳格に扱うべきです。

ソーシャルエンジニアリングとの組み合わせ

CSRFでは、ユーザーを攻撃者のページへ誘導する工程が必要です。攻撃者は、偽のキャンペーン、業務連絡、ニュース、社内チャット、SNS投稿、フィッシング詐欺メールなどを使い、クリックを誘います。

利用者教育では、「リンクを開いただけでは何も起きない」という前提を避けます。ログイン中のサービスがある状態で不審なリンクを開く行為は、意図しないリクエスト送信につながる場合があります。

CSRF攻撃への対策

CSRF対策の中心は、サーバ側でリクエストの正当性を検証することです。ユーザーの注意だけでは防げないため、Webサービス側は状態変更を伴う処理に対して複数の防御策を組み合わせます。

CSRFトークンの利用

CSRFトークンは、フォーム送信や状態変更リクエストに付与する推測困難な値です。サーバ側は、セッションに紐づくトークンとリクエスト内のトークンを照合し、一致しないリクエストを拒否します。攻撃者の第三者ページからは正しいトークンを付けにくいため、CSRF対策の中心になります。

実装時は、トークンを十分に長く推測困難にする、セッションと紐づける、状態変更リクエストで検証する、ログに不用意に残さない、XSS対策と併用する、といった点を確認します。XSSが存在するとトークンが読み取られる場合があるため、CSRFトークンだけで全体の安全性を担保する設計は避けます。

SameSite属性の活用

CookieのSameSite属性は、クロスサイトリクエストでCookieを送るかどうかを制御する仕組みです。SameSite=LaxやSameSite=Strictを設定すると、第三者サイトからのリクエストにCookieが付与される範囲を制限でき、CSRFリスクの低減に役立ちます。

ただし、SameSite属性はCSRFトークンの完全な代替ではありません。外部連携、決済、シングルサインオン、ブラウザの挙動差などの影響を受けるため、重要な状態変更処理ではCSRFトークン、Origin検証、再認証などと組み合わせます。

Origin / Refererの検証

OriginやRefererヘッダーを確認し、想定外の外部サイトから届いたリクエストを拒否する方法もあります。特にOriginヘッダーは、状態変更リクエストの送信元確認に使われます。

一方で、ヘッダーが欠落するケースや、プロキシ、ブラウザ設定、プライバシー保護機能の影響を受けるケースがあります。そのため、Origin / Refererの検証は単独の防御策ではなく、CSRFトークンやSameSite属性を補完する対策として扱います。

GETで状態変更を行わない

GETリクエストは、本来、情報取得に使うメソッドです。リンクのクリック、画像読み込み、プリフェッチなどで発生しやすいため、GETで送金、削除、設定変更、購入などを実行できる設計はCSRFの影響を受けやすくなります。

状態変更を伴う処理は、POST、PUT、PATCH、DELETEなど適切なメソッドを使い、CSRFトークン検証、権限確認、再認証を組み合わせます。メソッドを変えるだけでは十分ではありませんが、リンクを踏むだけで状態変更が完了する設計は避けるべきです。

重要操作で再認証・確認を行う

送金、決済、パスワード変更、認証設定変更、管理者権限付与、APIキー発行などは、CSRF成功時の影響が大きい操作です。これらの処理では、再認証、ワンタイムコード、確認画面、変更通知、監査ログを組み合わせます。

特に管理画面では、ログイン状態が長く続くことがあります。セッションタイムアウト、アイドルタイムアウト、権限の最小化、操作ログの確認を組み合わせると、CSRFだけで重大操作が完了するリスクを下げられます。

エンドユーザー側でできるリスク低減

CSRFは主にWebサービス側の実装で防ぐべき攻撃ですが、利用者側の行動で成立条件を減らせる場合があります。特に、管理画面、金融サービス、業務SaaSを扱う利用者は、ログイン状態とリンククリックの扱いに注意します。

重要サービスのログイン状態を管理する

金融サービス、管理画面、業務SaaS、ECサイトの管理機能などを使い終えたらログアウトします。共有端末や共用ブラウザでは、ログイン状態を残さない設定を使います。セッションが無効であれば、CSRFによる状態変更は成立しにくくなります。

不審なリンクを開かない

メール、SNS、チャットに届いたリンクは、送信元が正規に見えても確認します。アカウント乗っ取りにより、実在の相手から不正リンクが送られる場合もあります。特に、急ぎの確認、特典、警告、請求、ファイル共有を装う文面は慎重に扱います。

ブラウザとOSを最新に保つ

CSRFそのものはWebアプリケーション側の検証不足で成立しますが、Cookie制御、サイト分離、セキュリティ機能はブラウザの更新で改善されます。OS、ブラウザ、拡張機能を更新し、不要な拡張機能を削除しておくと、関連リスクを減らせます。

CSRFと関連するWebセキュリティ脅威

CSRFだけを対策しても、Webアプリケーション全体の安全性は確保できません。XSSやSQLインジェクションなど、別の脆弱性と組み合わさると被害が広がるため、関連する攻撃との違いを把握しておく必要があります。

XSSとの違い

XSSは、Webページに不正なスクリプトを混入させ、ユーザーのブラウザ上で実行させる攻撃です。CSRFは、ユーザーのブラウザから正規サイトへ不正リクエストを送らせる攻撃です。XSSはブラウザ上でコードを動かす点、CSRFはセッション付きリクエストを悪用する点が異なります。

XSSが存在すると、CSRFトークンの読み取り、画面改ざん、利用者の操作誘導が可能になる場合があります。そのため、CSRFトークンを実装していても、XSS対策が不十分であればCSRF耐性が弱まります。

SQLインジェクションとの違い

SQLインジェクションは、入力値を通じて不正なSQLを実行し、データベースの読み取り、改ざん、削除を狙う攻撃です。CSRFは、ログイン済みユーザーの権限でWebアプリケーションの正規機能を実行させる攻撃です。

両者は攻撃対象が異なりますが、どちらも「想定外の操作が通る」設計不備から被害が生じます。入力値の検証、権限確認、状態変更リクエストの検証、ログ監視を組み合わせて、Webアプリケーション全体で対策します。

まとめ

CSRF攻撃は、ログイン中のユーザーのブラウザを利用して、本人が意図しない状態変更リクエストを送信させる攻撃です。被害は、購入、送金、アカウント設定変更、権限付与、APIキー発行などに及びます。

対策の中心は、CSRFトークンによるリクエスト検証です。あわせて、SameSite属性、Origin / Referer検証、GETで状態変更を行わない設計、重要操作の再認証、操作ログ、通知を組み合わせます。利用者側でも、重要サービスのログイン状態を管理し、不審なリンクを避け、ブラウザやOSを更新することでリスクを下げられます。