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

はじめに

インターネットの普及に伴い、私たちの生活は大きく変わりました。情報の取得・コミュニケーション・ショッピングなど、多くの活動がオンライン上で行われるようになった一方で、その便利さの裏にはさまざまなセキュリティリスクが潜んでいます。

その中でもCSRF攻撃は、ユーザー本人が気づかないまま「ログイン中の権限」を悪用され、意図しない操作を実行させられる可能性がある点で注意が必要です。本記事では、CSRFの仕組み、起こりやすいシナリオ、そして実務で使える対策の考え方を整理します。

サイバー攻撃とは？ 種類と対策をわかりやすく解説 | ネットアテスト

企業が活動を続けるなかでセキュリティ対策は欠かせません。情報化が進んだことで企業が持つ情報の価値は高まり、サイバー攻撃の標的になるようになったからです。適切なセキュリティ対策を取るためには、サイバー攻撃の種類についてもしっかりと理解しておく必要があります。この記事では、企業が注意...

netattest.com

CSRF攻撃とは

CSRF（Cross-Site Request Forgery：クロスサイトリクエストフォージェリ）攻撃とは、ユーザーが意図しない操作（リクエスト）を第三者のページを経由して、正規サイトに送信させる攻撃手法です。ポイントは、攻撃対象のサイトに「ログイン済み」のユーザーが、攻撃者の用意したページ（罠ページ）を開くことで、ユーザーの名義で処理が進んでしまう可能性がある点です。

たとえば、ログイン中に「メールアドレス変更」「送金」「パスワード変更」「配送先住所の変更」「権限変更」などの操作が、本人の意思とは無関係に実行されると、被害は金銭・信用・アカウント支配にまで広がります。

CSRF攻撃の基本

ウェブサイトやオンラインサービスを利用する際、私たちは「自分がクリックした操作だけが実行される」と考えがちです。しかしブラウザは、ユーザーの利便性のために、ログイン状態を維持する仕組み（セッション）を自動的に扱います。CSRFは、その便利さが裏目に出る典型例です。

クロスサイトリクエストフォージェリの定義

CSRFは、第三者のウェブサイトやメール、SNS投稿などを踏み台にして、ユーザーが意図しないリクエストを送信させる攻撃です。攻撃者が狙うのは、ユーザーのパスワードそのものではなく、ログイン済みのセッション（「本人として操作できる状態」）です。

CSRFの動作メカニズム

CSRFが成立する背景には、主に以下の2点があります。

• ブラウザは、同一サイト宛のリクエストにCookieを自動付与する（ログイン状態が維持される）
• サーバ側が「そのリクエストが本人の意思で送られたか」を判別できない設計がある

具体的には、ユーザーが対象サイトにログインしている状態で、攻撃者の罠ページを開きます。罠ページは、画像表示・自動送信フォーム・スクリプトなどを使って、対象サイトに対するリクエストを発生させます。このときブラウザは、対象サイト宛の通信であれば、ユーザーのCookie（セッション情報）を付けて送ってしまうため、サーバ側は「ログイン済みユーザーからの正規リクエスト」として処理してしまう可能性があります。

成立条件

CSRFは「いつでも」成立するわけではありません。典型的には次の条件が重なると危険です。

• ユーザーが対象サイトにログイン済み（セッションが生きている）
• 状態を変更する操作（送金・変更・削除など）が、CSRF対策なしで実行できる
• リクエストの正当性確認が「Cookieによるログイン判定だけ」で済んでいる

なぜCSRFは危険なのか

CSRFの厄介さは、ユーザーが攻撃に参加している自覚がほとんどない点にあります。操作画面を開いたわけでも、確認ボタンを押したわけでもないのに、裏側で処理が完了してしまうケースがあります。

さらに、被害が「アカウント情報の変更」「送金」「権限付与」など不可逆・重大な操作に及ぶと、ログを確認するまで気づけないこともあります。つまりCSRFは、攻撃の成功後に発見されるまでの時間が長くなりやすいという意味でも危険です。

CSRF攻撃の具体的な例

CSRFの理屈が分かっても、「どの操作が狙われるのか」を具体的に想像できないと対策は定着しません。ここでは典型的なシナリオをいくつか見ていきます。

ウェブサイトの機能を悪用した攻撃

例として、オンラインショッピングサイトを考えます。ログイン後の状態で、攻撃者のページにアクセスすると、背後で「カートへ追加」「配送先の変更」「注文確定」などのリクエストが送信される可能性があります。ユーザーはただページを開いただけでも、セッションが有効であれば、サーバが正規操作として扱ってしまう場合があります。

狙われやすい操作

• メールアドレスやパスワード、二要素認証設定などのアカウント設定変更
• 送金・購入・課金などの金銭に直結する処理
• APIキー再発行、権限付与、招待送信などの権限・セキュリティ関連操作

ソーシャルエンジニアリングを組み合わせた攻撃

CSRF単体でも成立しますが、実務上は「罠ページへ誘導する」工程でソーシャルエンジニアリングが使われがちです。例えば、偽のプロモーションメール、興味を引くニュース見出し、SNSの投稿、社内チャットのなりすましリンクなどでクリックを誘います。誘導が成立すると、ユーザーは「リンクを開いただけ」で攻撃に巻き込まれる可能性があります。

被害が大きくなりやすいパターン

CSRFは「ログイン済みの権限」を利用するため、被害はそのサービスの権限範囲に依存します。特に、管理者権限・経理権限などの強い権限を持つアカウントが狙われると、影響が組織全体に及びます。

また、攻撃者が別の脆弱性（例：XSS）と組み合わせると、ユーザー誘導がより確実になったり、実行できる操作が増えたりするため、被害が拡大しやすくなります。

CSRF攻撃の対策

CSRFは「仕組み上起きうる」攻撃であるため、気合や注意だけでは防ぎきれません。基本は、サーバ側で“本人の意思”を確認できる仕組みを入れることです。ここでは、ウェブサイト側（提供側）とエンドユーザー側（利用側）に分けて整理します。

ウェブサイト側の対策

ウェブサイトを運営する側は、状態を変更する処理（更新・削除・送金・設定変更など）に対して、CSRF対策を組み込むことが重要です。代表的な手段を紹介します。

CSRFトークンの利用

フォーム送信や状態変更のリクエストに対して、一意のトークン（推測困難な値）を付与し、サーバ側で照合する方法です。攻撃者のページから勝手に送られたリクエストには正しいトークンを付けられないため、不正リクエストを排除できます。

実装では「セッションに紐づくトークンを発行し、送信ごとに検証する」「使い回しを避ける」「重要操作は再認証や確認を要求する」など、運用面も含めて設計します。

SameSite属性の活用

CookieのSameSite属性を適切に設定することで、第三者サイトからのリクエストにCookieが付与されにくくなり、CSRFリスクを下げられます。特に、可能な範囲でSameSite=Lax/Strictを検討し、例外が必要なケース（外部連携や決済など）は、設計意図を明確にしたうえで調整します。

Referer / Originのチェック

リクエスト元の情報（RefererやOrigin）を検証し、想定外の外部サイトからのリクエストを拒否する方法です。ただし、ブラウザ設定やプロキシ、プライバシー保護の影響で情報が欠落する場合もあるため、これ単体に依存せず補助的に使うのが現実的です。

設計上の基本ルール

• 状態変更はGETで行わない（リンクを踏むだけで実行される設計を避ける）
• 重要操作は確認画面・再入力・再認証などを挟む（ワンクリックで完了させない）
• 権限操作・認証設定・送金などは特に厳格にする（被害の上限を下げる）

エンドユーザーの対策

CSRFは主にサーバ側の設計で防ぐべきですが、ユーザー側の習慣でリスクを下げられる場面もあります。

ログイン状態の扱いを意識する

重要なサービス（金融、管理画面、業務SaaSなど）を使い終えたらログアウトする、共有端末でログイン状態を残さない、といった基本動作は有効です。セッションが生きていなければCSRFの成立条件が崩れます。

不審なリンク・添付ファイルに注意する

メールやSNS、チャットに届いたリンクは、送信元が正規でも乗っ取りの可能性があります。特に「急かす」「得をする」「警告を装う」文面は誘導の典型です。リンク先を開く前に、URLや文脈を確認する習慣が役立ちます。

ブラウザ・OS・拡張機能を最新に保つ

CSRFそのものは仕組みの問題ですが、関連する挙動（Cookie制御、セキュリティ機能、サイト分離など）はブラウザの更新で改善されることがあります。普段使いの環境は継続的にアップデートしておくのが安全です。

CSRF以外のウェブセキュリティ脅威

CSRFだけを対策しても、別の入口から同様の被害が起こることがあります。関連性が高く、混同されやすい代表例を整理します。

XSS（クロスサイトスクリプティング）との違い

XSSは、攻撃者がウェブページに悪意のあるスクリプトを混入させ、ユーザーのブラウザ上で不正な処理を実行させる攻撃です。CSRFは「ユーザーのセッションを使ってサーバへ不正リクエストを送らせる」攻撃であり、狙いどころが異なります。

ただし、XSSがあると「ユーザーを罠ページへ誘導する」「CSRFトークンを盗む」などが現実味を帯び、結果としてCSRF被害が拡大しやすくなります。つまり、実務ではどちらも同時に潰す視点が重要です。

SQLインジェクションとの関連性

SQLインジェクションは、入力値を通じて不正なSQLを実行し、データベースを読み書きする攻撃です。CSRFが「正規ユーザーの権限で処理を実行させる」攻撃であるのに対し、SQLインジェクションは「アプリの入力処理不備を突いて裏側のDBを直接操作する」攻撃です。

攻撃は別物ですが、どちらも「想定外の操作が通る」ことが根本原因になりやすいため、入力検証・権限設計・ログ監視などの基本に立ち返ることが有効です。

まとめ

CSRF攻撃は、ユーザーがログインしている状態（セッション）を悪用し、本人が意図しない操作を実行させる脅威です。被害は金銭・設定変更・権限操作などに及び得るため、ウェブサービスにとって無視できません。

CSRF攻撃の重要性の再確認

CSRFの本質は「リクエストが本人の意思かどうか」をサーバ側が判断できない点にあります。したがって、対策の中心は、CSRFトークンやSameSite属性などを用いて、不正リクエストを成立させない仕組みを実装することです。

日常のウェブ利用における注意点

ユーザー側でも、重要サービスのログイン状態を長く残さない、不審なリンクを踏まない、環境を最新に保つといった基本動作で、成立条件を減らせます。サービス提供側・利用側の双方が前提を理解し、実装と運用を積み重ねることが、CSRFを現実的に抑え込む近道です。