CSRF

この用語をシェア

CSRFとは

CSRF（Cross-Site Request Forgery、クロスサイトリクエストフォージェリ）とは、ユーザーが信頼するWebサイトに対して、ユーザーの意図しない不正なHTTPリクエストを送信させるWebアプリケーション脆弱性の一種です。攻撃者は、ユーザーがログイン状態にあるWebサイトに対して、悪意のあるリクエストを実行させることで、パスワード変更、データ削除、不正送金などの操作を行わせます。

CSRF攻撃の仕組み

1. 攻撃のシナリオ

ユーザーが銀行サイトにログインした状態で、攻撃者が用意した悪意のあるWebサイトを訪問すると、そのサイトから銀行サイトへの送金リクエストが自動的に送信される、といった攻撃が典型例です。

<!-- 攻撃者のサイトに埋め込まれた悪意のフォーム -->
<form action="https://bank.example.com/transfer" method="POST">
  <input type="hidden" name="to" value="attacker-account" />
  <input type="hidden" name="amount" value="10000" />
</form>
<script>
  document.forms[0].submit(); // 自動送信
</script>

2. 攻撃が成功する条件

• ユーザーが対象サイトにログイン状態である
• 対象サイトがCSRF対策を実装していない
• 攻撃者が対象サイトのリクエスト形式を知っている
• ユーザーが攻撃者の用意したサイトや悪意のあるメールを閲覧する

CSRF対策手法

1. CSRFトークン

最も一般的で効果的な対策です。各フォームにランダムなトークンを含め、サーバー側でトークンの妥当性を検証します。

<!-- HTML側：CSRFトークンをフォームに埋め込み -->
<form action="/transfer" method="POST">
  <input type="hidden" name="csrf_token" value="{{ csrf_token }}" />
  <input type="text" name="amount" />
  <button type="submit">送金</button>
</form>

// サーバー側（Node.js例）：トークン検証
app.post('/transfer', (req, res) => {
  if (req.body.csrf_token !== req.session.csrf_token) {
    return res.status(403).send('CSRF token invalid');
  }
  // 正常な処理を継続
});

2. SameSite Cookie属性

Cookieの送信をファーストパーティコンテキストに制限することで、クロスサイトからのリクエストでセッションCookieが送信されることを防ぎます。

// SameSite属性の設定例
res.cookie('session', sessionId, {
  sameSite: 'strict', // または 'lax'
  secure: true,       // HTTPS必須
  httpOnly: true      // XSS対策
});

// Express.js session設定例
app.use(session({
  cookie: {
    sameSite: 'strict',
    secure: true,
    httpOnly: true
  }
}));

3. Origin/Refererヘッダー検証

リクエストの送信元を検証することで、信頼できるドメインからのリクエストかを確認します。

// Origin ヘッダー検証例
app.use((req, res, next) => {
  const origin = req.get('Origin');
  const referer = req.get('Referer');
  
  if (req.method === 'POST') {
    if (!origin && !referer) {
      return res.status(403).send('Missing origin header');
    }
    
    const allowedOrigins = ['https://example.com'];
    if (!allowedOrigins.includes(origin)) {
      return res.status(403).send('Invalid origin');
    }
  }
  
  next();
});

主要な対策手法のメリット・デメリット

CSRF対策には複数の手法があり、それぞれ実装コストと保護範囲が異なります。単独ではなく組み合わせて使うのが基本ですが、各手法の特性を理解しておくことが重要です。

• CSRFトークン — メリット：最も確実で広く実績のある対策。デメリット：フォームやAPIごとにトークンの発行・検証ロジックを実装する手間がかかる
• SameSite Cookie属性 — メリット：ブラウザ側で自動的に保護され実装コストが低い。デメリット：古いブラウザでは非対応の場合があり、正規のクロスサイト連携（決済連携等）が意図せずブロックされることがある
• Origin/Refererヘッダー検証 — メリット：追加実装が比較的簡単。デメリット：プライバシー設定やプロキシ環境でヘッダーが送信されないケースがあり、単独では信頼性が低い
• Double Submit Cookie — メリット：サーバー側でセッション状態を保持しないステートレスな実装が可能。デメリット：Cookie自体がXSSで盗まれると防御が突破される

フレームワーク別の実装

現代的な対策の組み合わせ

セキュリティテスト

CSRF脆弱性の検出には、以下のツールやアプローチが有効です：

# OWASP ZAP でのCSRF脆弱性テスト
# 自動スキャンでCSRF脆弱性を検出

# Burp Suite での手動テスト
# 1. 正常なリクエストをキャプチャ
# 2. CSRFトークンを削除または無効な値に変更
# 3. リクエストを再送信してレスポンスを確認

# curl での簡易テスト例
curl -X POST https://example.com/transfer \
  -d "to=attacker&amount=1000" \
  -H "Cookie: session=victim_session" \
  --referer "https://malicious.com"

関連技術

CSRFとXSSの違い

CSRFとXSSはどちらもWebアプリケーションを狙う代表的な攻撃手法ですが、仕組みと対策は異なります。両者を混同すると対策が不十分になるため、違いを正しく理解することが重要です。

実務での活用シーン・注意点

受託開発やフリーランス案件でCSRF対策を扱う際の実務ポイントは以下の通りです。

• フォーム・状態変更APIの実装時は必ずCSRF対策を組み込む：新規開発案件では、フレームワーク標準のCSRF保護機能（Django・Rails・Spring Security等）をデフォルトで有効にしたまま運用するのが基本
• SPA＋API構成では対策方法を要確認：SPAからのAPI呼び出しではCookieベース認証かトークンベース認証（Bearerトークン等）かによって、CSRF対策の要否・実装方法が変わる。トークンをlocalStorage等で管理しCookieを使わない構成ではCSRFリスク自体が低い場合がある
• 既存システムの保守案件では対策の有無をまず確認：レガシーシステムの改修依頼を受ける際は、既存のCSRF対策の実装状況（トークンの有無、SameSite属性設定）を最初にチェックする
• 注意点：GETリクエストで状態変更処理を行わない：GETは本来べき等であるべきで、状態変更をGETで実装するとCSRF対策の効果が薄れる設計上の問題につながる

2025〜2026年の最新動向

2025年はSameSite Cookie属性のデフォルトLax化により、CSRFリスクは大幅に低減。ただしクロスオリジン認証フローでの対策は引き続き重要です。

よくある質問（FAQ）

外部リンク・参考資料

• OWASP - CSRF

関連用語

この用語についてもっと詳しく

CSRFに関するご質問や、セキュリティ対策のご相談など、お気軽にお問い合わせください。