【実務・中級編】 CSRF(クロスサイトリクエストフォージェリ)の攻撃シーケンスと対策 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

CSRFは「死んだ」のか？：現場で直面する現代的なリクエスト強奪と防衛論

「CSRFなんて古い脆弱性だろ？今さら？」

もし君がそう思っているなら、残念だが君のシステムは既に誰かの踏み台にされているかもしれない。確かにモダンなフレームワークはCSRF対策を標準搭載している。だが、現場の泥臭い実装や、レガシーなバックエンドと疎結合なフロントエンドが混在する環境では、CSRFは依然として「安易に踏み抜ける地雷」として放置されているんだ。

今日は、教科書的な「Anti-CSRFトークンを入れろ」という話の先、「なぜそれが突破されるのか」「どう実装すれば絶対に突き破られないか」を、実戦的なコードと共に解説する。

—

1. 攻撃者が狙う「盲点」：CSRFの現在地

CSRFの本質は、ユーザーの「認証情報（Cookie）」を勝手に利用して、攻撃者の意図するリクエストを投げさせることにある。

多くのエンジニアが犯す最大の過ちは、「POSTリクエストだけ守ればいい」と思い込んでいることだ。最近のアプリケーションでは、JSONの送信にContent-Type: application/jsonを使うケースが多い。ここで油断が生まれる。

攻撃シーケンスのリアル

攻撃者は、被害者がログイン中のWebサイトに対して、以下のような巧妙なHTMLを仕込んだ罠サイトを閲覧させる。

<!-- 攻撃者のサーバーに設置された罠 -->
<!-- フォーム送信を自動化し、ユーザーの意図しない変更を強制する -->
<form id="attack-form" action="https://victim-site.com/api/v1/update-email" method="POST" enctype="text/plain">
    <input name='{"email":"attacker@evil.com", "dummy":"' value='"}'>
</form>
<script>
    // ページ読み込みと同時に自動送信
    document.getElementById('attack-form').submit();
</script>

もしサーバー側がContent-Typeの厳密な検証を怠っていれば、これだけで設定変更が通ってしまう。これが「POSTなら安全」という神話の末路だ。

—

2. 現代の「鉄壁」防御アーキテクチャ

防御の基本は多層構造だ。一つが欠けても全体が崩れない設計にする。

対策1：SameSite属性（Cookieの防波堤）

まずはブラウザレベルでの防御。Set-CookieヘッダーでSameSite=Lax（またはStrict）を強制する。これは現代のブラウザにおける「最低限の礼儀」だ。

Nginxでの設定例:

# 全てのCookieに対してSameSite属性を付与する設定
# セキュリティの要であるCookieの送受信を制御する
proxy_cookie_path / "/; HTTPOnly; Secure; SameSite=Lax";

対策2：ステートフルなAnti-CSRFトークン

SameSiteは万能ではない。古いブラウザや、クロスサイト遷移時の挙動には隙がある。やはり、サーバー側で検証するトークンが最強だ。

PHPでの堅牢なトークン検証実装:

<?php
session_start();

// トークン生成（ログイン時やセッション開始時に実行）
if (empty($_SESSION['csrf_token'])) {
    $_SESSION['csrf_token'] = bin2hex(random_bytes(32));
}

// リクエスト処理時の検証
function validate_csrf_token($request_token) {
    if (!isset($_SESSION['csrf_token']) || !hash_equals($_SESSION['csrf_token'], $request_token)) {
        // ログを記録し、即座にセッションを破棄して遮断する
        error_log("CSRF attack detected!");
        header('HTTP/1.1 403 Forbidden');
        exit('CSRF check failed.');
    }
}

// 利用側のイメージ（フォームに隠しフィールドとして埋め込む）
// <input type="hidden" name="csrf_token" value="<?php echo $_SESSION['csrf_token']; ?>">

—

3. 実務で「絶対やってはいけない」アンチパターン

現場でよく見る「なんとなく安全そうな実装」が、実は一番危ない。

1. GETリクエストで状態を変更する: 論外だ。ログに残るし、Refererヘッダーを誤魔化すだけで踏み抜ける。
2. トークンをCookieに保存してフロントで読み取る: XSSでトークンが盗まれた瞬間、CSRF対策も無効化される。トークンは必ずサーバーサイドのセッションで管理しろ。
3. カスタムヘッダー（X-Requested-With等）を過信: CORSの設定ミスと組み合わさると、攻撃者がカスタムヘッダーを付与してリクエストを投げることは容易だ。

—

4. チーフからの提言：セキュリティは「性悪説」で設計しろ

Webアプリケーションの脆弱性は、コードのバグというよりも「設計の甘さ」から生まれることが多い。

「全ての変更操作（POST/PUT/DELETE）には必ずトークン検証を入れる」
「APIであっても認証済みのセッションを使うならトークン検証を省かない」
「WAFはあくまで最後の砦。コード自体を叩かれないように作る」

もし君が今日から修正を行うなら、まずは全エンドポイントで「トークンの有無」を確認するミドルウェアを一つ導入することから始めてほしい。それが、君のシステムをインシデントの泥沼から救う第一歩になる。

脆弱性を見つけるのが遅いか早いか。その差は、攻撃者の思考をどれだけリアルにシミュレーションできているかという一点に尽きる。明日、自分のコードを見直すとき、ぜひ「自分が一番の攻撃者だったらどこを突くか」を自問自答してみてくれ。