なぜ、今さら「CSRF」を語るのか？――その油断が、企業の信頼を焼き尽くす
「CSRF（クロスサイトリクエストフォージェリ）？ 今どきフレームワークが勝手にやってくれるし、対策済みでしょ？」
もし君がそう思っているなら、今すぐその考えを捨ててほしい。私が過去に見てきたインシデントの多くは、フレームワークに依存しすぎて「なぜ動いているのか」を理解していない開発者が、設定を一行書き換えた瞬間に生まれたものだ。
CSRFは、ユーザーのブラウザを「操り人形」にする攻撃だ。攻撃者は、認証済みのユーザーに悪意あるサイトを開かせるだけで、君のアプリケーションに対して「パスワード変更」や「送金」といった破壊的なリクエストを送信させることができる。
今日は、教科書的な説明は飛ばす。現場の視点で、この攻撃の真の恐ろしさと、二度と穴を開けないための鉄壁の実装法を叩き込む。
—
1. 攻撃者が狙う「盲点」：ステートフルとステートレスの狭間
CSRFの本質は、「ブラウザが自動的にクッキーを送信する」というWebの基本仕様を逆手に取る点にある。
- ステートフルな攻撃: セッションIDをクッキーで管理している場合、攻撃者は何も考えずにリクエストを投げるだけでいい。ブラウザが勝手に「正当なセッションID」を付与してくれるからだ。
- ステートレス（API）の誤解: 最近はJWT（JSON Web Token）を使った認証も多い。だが、「Authorizationヘッダーに入れているから安全」と高を括っていないか？ ローカルストレージに保存したトークンをJSで読み取り、ヘッダーに含める実装なら確かにCSRFは防げる。しかし、もし君が「利便性のために」トークンをクッキーに保存する構成にしていたら、その瞬間、君のAPIはCSRFに対して無防備な要塞と化す。
—
2. 現場で使える「鉄壁」の防御：Anti-CSRF Tokenの実装
防御の基本は、「リクエストが本当にユーザーの意図したものか」を検証することだ。サーバー側で発行した「予測不可能なトークン」をリクエストに含め、それが一致しなければ弾く。これ以外の小細工（Refererチェックなど）は、ネットワーク環境やブラウザの挙動次第で簡単にバイパスされるため、補助輪程度に考えるべきだ。
Python (Flask) でのセキュアな実装例
ライブラリに頼るのもいいが、まずは自力で実装するならこうなる。
import secrets
from flask import Flask, request, session, abort
app = Flask(__name__)
app.secret_key = ‘super-secret-key’ # 本番では環境変数から読み込むこと
トークンの生成と検証用関数
def generate_csrf_token():
if ‘_csrf_token’ not in session:
session[‘_csrf_token’] = secrets.token_hex(32) # 暗号論的に安全な乱数を使用
return session[‘_csrf_token’]
@app.route(‘/transfer’, methods=[‘POST’])
def transfer_funds():
# クライアントから送られてきたトークンと比較
token = request.form.get(‘_csrf_token’)
if not token or token != session.get(‘_csrf_token’):
# 認証失敗時は即座にセッションを切るくらいの厳しさで良い
abort(403, “CSRF Token Validation Failed”)
# 正常な処理…
return “Success”
JavaScript (フロントエンド) での送出
フォーム送信時、またはfetch/axiosでリクエストを送る際に、隠しフィールドやカスタムヘッダーでトークンを注入する。
// fetchで送信する際のセキュアなヘッダー付与
const csrfToken = document.querySelector(‘meta[name=”csrf-token”]’).content;
fetch(‘/transfer’, {
method: ‘POST’,
headers: {
‘Content-Type’: ‘application/json’,
‘X-CSRF-TOKEN’: csrfToken // カスタムヘッダーで送るのがモダンな手法
},
body: JSON.stringify({ amount: 1000 })
});
—
3. インフラ層でのダメ押し：SameSite Cookie属性
コードレベルの対策に加え、Webサーバーやフレームワークの設定で「クッキーの出し方」を制御する。これが最後の砦だ。
Nginx や アプリケーション側のレスポンスヘッダー設定:
Set-Cookie: session_id=abc123xyz; Secure; HttpOnly; SameSite=Strict
- SameSite=Strict: どんな状況でも、自分自身（同一サイト）からのリクエストにしかクッキーを付与しない。これが最強だ。
- SameSite=Lax: デフォルトで推奨される設定。トップレベルの遷移（リンククリックなど）ではクッキーを送るが、POSTなどの破壊的なリクエストには送らない。
もし君のアプリが金融系や管理画面なら、迷わず Strict を選べ。
—
4. プロの視点：最後に君たちへ伝えたいこと
CSRF対策を実装した後に必ずやってほしいことがある。それは「自分のアプリに対して自分で攻撃してみること」だ。
1. Burp SuiteやOWASP ZAPを使って、自分のリクエストをキャプチャする。
2. 攻撃用のHTMLファイルをローカルに作り、action先を自分のアプリのPOSTエンドポイントに向け、_csrf_tokenを削除して送信してみる。
3. そこで 403 Forbidden が返ってくれば、君の勝ちだ。
セキュリティは「設定して終わり」ではない。「意図した通りに制限が効いているか」を泥臭く確認するプロセスこそが、エンジニアを一流へと引き上げる。
コードを書くとき、常に問いかけてほしい。「もしこのリクエストが、悪意ある第三者によって勝手に送られたら、システムはどうなる？」と。その疑念こそが、君のアプリケーションを守る最強の盾になるはずだ。
現場からは以上だ。次回のコードレビューで、脆弱な実装を見つけるのを楽しみにしているよ。
コメント