CSRFとは？

CSRFが発生するリスクが高まる条件

CSRF攻撃の被害例

利用者が知らずに被るリスク

• 勝手にSNSへ投稿され、フォロワーを巻き込んでしまう
• ショッピングサイトで意図しない商品を購入される
• パスワードやメールアドレスを第三者に変更される
• オンラインバンキングから知らない相手に送金される

Webサービス側に発生する被害

• スパム投稿や不正アクセスによるブランドイメージの悪化
• 顧客情報の改ざん・消失による業務トラブル
• 脆弱性を放置していたことによる法的責任・行政指導
• 謝罪・調査・補償といった対応に伴うコストの増加

実際に発生したCSRF攻撃の事例

• EC構築システムの脆弱性を突いたカード情報漏えい
  2019年、EC構築システムA社に存在していたCSRF脆弱性により、決済画面が改ざんされ、クレジットカード情報が外部に送信される被害が多数発生しました。
  参照：IPA「A社システム脆弱性に関する注意喚起」


• CSRFによる高額送金被害の発生
  オンラインバンキングにおいて、CSRFを用いた自動送金スクリプトが組み込まれ、利用者の意図しない送金が発生。
  被害者がページを開いただけで送金処理が完了していたと報じられています。
  参照：Yahoo!ニュース「送金詐欺に使われた手口とその影響」


• SNSでのスパム拡散（通称：はまちちゃん事件）
  掲示板に設置された悪意あるリンクを踏んだユーザーが、意図せずSNSでスパム投稿を行う事件が発生しました。
  これは掲示板のフォーム設計にCSRF対策がなされていなかったことが原因とされます。
  参照：ITmedia「“はまちちゃん騒動”に見る掲示板の脆弱性」

CSRFの具体的な攻撃方法

CSRF攻撃の流れ（全体像）

1. 1. ユーザーAが、正規のWebアプリケーションにログイン。
2. 2. ログイン状態のまま、攻撃者が仕込んだ「罠ページ」を開いてしまう。
3. 3. 罠ページに仕込まれたスクリプトが、勝手にパスワード変更などのリクエストを送信。
4. 4. 正規サイトは、セッション情報をもとにリクエストを正当と判断し、操作が実行されてしまう。

典型的なCSRF攻撃のステップ

1. ① 自分がWebサービスにログイン
   例えば、ネットバンキングやショッピングサイトなど、認証が必要なサービスにログインした状態のままブラウザを閉じたり、別タブで他のサイトを見たりします。


2. ② 攻撃者が罠ページを用意
   攻撃者は、Webページや広告、SNS投稿などに、対象サービスへの「不正な操作」を仕込んだHTMLやJavaScriptを埋め込みます。


3. ③ 自分が罠ページを開いてしまう
   メールのリンク、SNSのDM、怪しい広告などをうっかり開いてしまうと、そのページが裏で勝手にリクエストを送信します。


4. ④ 自分のログインセッションが使われて不正操作が実行
   Webサービス側は「正しいユーザーからの操作」と誤認し、パスワード変更・送金・投稿などが実行されてしまいます。

要点まとめ

GETメソッドを悪用したケース

POSTメソッドを悪用したケース

<form action="https://example.com/post-message" method="POST">
  <input type="hidden" name="message" value="スパム投稿です！">
</form>
<script>
  document.forms[0].submit();
</script>

• フォームを自動で送信する仕組み
• iframeとJavaScriptを組み合わせた埋め込み
• AJAX（非同期通信）を使ったリクエスト
• FlashやJava Appletなどのプラグイン（現在は減少傾向）

【誤解に注意】CSRFとフィッシングの違いを整理しよう

• フィッシング：
  ユーザーに「偽のログイン画面などに自分で情報を入力させる」ことで、IDやパスワードを盗む攻撃です。


• CSRF：
  ログイン中のユーザーに「何も気づかせずに操作をさせる」ことで、ユーザー本人の権限で不正処理を実行させる攻撃です。

CSRFとXSSの違いと関係性

CSRF攻撃を受けやすいサイトの特徴とは？

設計・実装に起因するリスク要因

1. Cookie認証に依存したセッション管理
   ・Cookie内のセッションIDのみで認証状態を維持している
   ・二次認証や追加の確認プロセスがない


2. リクエスト検証の不備
   ・フォーム送信時のトークン検証が実装されていない
   ・HTTPリクエストのRefererヘッダーチェックがない


3. 重要な操作の設計上の問題
   ・パスワード変更、メールアドレス変更などの操作に再認証がない
   ・GETメソッドで状態変更操作を実装している


4. セキュリティヘッダーの未設定
   ・SameSite Cookie属性が設定されていない、または不適切
   ・CSP（Content Security Policy）が未設定または不十分

リスクの高いWebサイトのタイプ

• 自動ログイン機能がある
  （ログイン状態を長く維持するため、悪用されやすくなります）
• 長期間ログイン状態が続く設定になっている
  （一度ログインすると何日も再認証されず、CSRFの標的になりやすい）
• 複数のサブドメインで同じCookieを使っている
  （別のドメイン経由でも認証情報が使えるため、攻撃の足がかりになります）
• APIへのアクセスにCSRF対策がされていない
  （アプリ内部や外部システムからのアクセス口に対策がなく、攻撃を受けやすくなります）
• 古いブラウザへの対応のため、セキュリティ設定を緩めている
  （SameSite属性やセキュリティヘッダーなどが正しく機能せず、脆弱になります）

CSRF攻撃を防ぐには？

CSRFトークン（ワンタイムトークン）の導入

<form action="/update-profile" method="POST">
  <input type="hidden" name="csrf_token" value="ランダムなトークン文字列">
  <input type="text" name="username">
  <button type="submit">送信</button>
</form>

Refererヘッダをチェックする

<?php
$referer = $_SERVER['HTTP_REFERER'] ?? '';
$allowed_domains = ['example.com', 'sub.example.com'];

$is_valid_referer = false;
foreach ($allowed_domains as $domain) {
  if (strpos($referer, $domain) !== false) {
    $is_valid_referer = true;
    break;
  }
}

if (!$is_valid_referer) {
  die('不正なリクエスト発生元です');
}
// 正当なリクエストの場合は処理を続行
?>

Refererチェックの注意点

• ユーザー側でRefererの送信を無効にしていると使えない
  （プライバシー設定や拡張機能でRefererヘッダーが送られない場合があります）
• HTTPS → HTTP のリクエストではRefererが自動的に省略される
  （セキュリティ上の仕様です）
• Refererは改ざんされる可能性がある
  （完全に信頼できる情報ではないため、「補助的な対策」として考えるべきです）

SameSite属性を活用する

SameSite属性の3つの設定値

SameSite属性の設定例（PHP）

<?php
setcookie(
  'session_id',
  '1234567890abcdef',
  [
    'expires' => time() + 3600,
    'path' => '/',
    'domain' => 'example.com',
    'secure' => true,
    'httponly' => true,
    'samesite' => 'Lax'  // SameSite属性をLaxに設定
  ]
);
?>

補足：最近のブラウザの挙動

注意点

ユーザー側も注意を払う

ユーザーができるCSRF対策の行動例

1. 重要なサイトは、利用後に必ずログアウトする
   特にネットバンキングや会員制サイトでは、ログイン状態のまま放置しないようにしましょう。


2. プライベートブラウジングや複数ブラウザの使い分け
   通常のWeb閲覧と、個人情報を扱うサイトは分けて利用するのが理想です。


3. 不審なリンクを開かない
   メールやSNSで届いた怪しいリンクは、安易にクリックせずにURLを確認する習慣を。


4. ブラウザを常に最新の状態に保つ
   モダンブラウザではセキュリティ機能（SameSite属性など）が日々強化されています。


5. セキュリティ拡張機能を利用する
   例：NoScriptやuBlock Originなどで、不審なスクリプトの実行を防げます。

まとめ：CSRF対策と共に、サイバー保険を