認証を「ハック」される恐怖：CSRFの正体と、SameSite属性の本当の使い所
現場でコードをレビューしていると、いまだに「CSRF（クロスサイトリクエストフォージェリ）？ うちのサイトは認証してるから大丈夫でしょ」と笑うエンジニアに出くわす。これが一番危ない。
CSRFは、ユーザーが認証済みであることを悪用する。「ユーザーのふりをする」のではなく、「ユーザーに意図しないリクエストを強制的に叩かせる」攻撃だ。セッションが生きているブラウザに対し、攻撃者が仕込んだ罠サイトから「パスワード変更」や「送金」のリクエストを裏で投げさせる。これがどれほど恐ろしいか、一度インシデント対応の現場に立つと身に染みるはずだ。
1. CSRFのメカニズム：なぜブラウザは「裏切り」を許すのか
CSRFが成立する大前提は、ブラウザが自動的にCookieを付与する仕様にある。
1. ユーザーが銀行サイトにログインし、セッションCookieがブラウザに保存される。
2. ユーザーが攻撃者の悪意あるサイトを開く。
3. そのサイト内の隠れたフォームやJavaScriptが、銀行サイトの「送金API」に対してPOSTリクエストを投げる。
4. ブラウザは「銀行サイトへのリクエストだ」と判断し、保存されていたセッションCookieを勝手に付けて送信する。
5. 銀行サーバーは、正しいセッションCookieを見て「本人の操作だ」と勘違いし、送金を実行する。
これが攻撃の全容だ。認証の壁は、この「自動付与」という仕様の前では無力に等しい。
—
2. SameSite属性：万能の盾ではない
現在、防御の第一線として推奨されるのがCookieのSameSite属性だ。設定値の挙動を正しく理解していないと、セキュリティホールを自ら開けることになる。
Strict: 最も堅牢。同じドメインからのみCookieが送信される。リンクをクリックして遷移した直後のリクエストでもCookieは送られない。UXを損なう可能性があるが、管理画面には必須。Lax: デフォルトの推奨値。トップレベルのナビゲーション（リンククリック等）ではCookieが送信されるが、POSTリクエストなどの副作用を伴う操作では送信されない。None: クロスサイトでもCookieを送信する。これを使うなら、必ずSecure属性（HTTPS必須）を併用しなければならない。
【注意点】 SameSite=Lax であっても、GETリクエストによるCSRFは防げない。データを書き換える処理（POST/PUT/DELETE）は、必ずこの属性だけに頼らず、後述するトークン検証を組み合わせるのが鉄則だ。
—
3. 実践：強固な防御のための実装サンプル
① Python (Flask) でのCSRFトークン実装
トークンを埋め込み、サーバー側で照合する。これがCSRF対策の王道だ。
from flask import Flask, session, request, abort
import secrets
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(16)
return session[‘_csrf_token’]
テンプレートに渡すための関数
app.jinja_env.globals[‘csrf_token’] = generate_csrf_token
リクエスト検証用デコレータ
def validate_csrf(f):
def wrapper(args, kwargs):
# 送られてきたトークンとセッション内のトークンを比較
token = request.form.get(‘_csrf_token’)
if not token or token != session.get(‘_csrf_token’):
abort(403) # トークン不一致なら即座に拒否
return f(args, kwargs)
return wrapper
@app.route(‘/transfer’, methods=[‘POST’])
@validate_csrf
def transfer():
# 送金処理…
return “送金成功”
② Nginx での Cookie SameSite 設定
アプリケーションコードをいじれないレガシーなシステムの場合、リバースプロキシ側で強制的に属性を付与する荒技もある。
nginx.conf の server または location ブロック内
すでに属性がある場合は上書きせず、ない場合のみ付与する設定
proxy_cookie_path / “/; HTTPOnly; Secure; SameSite=Lax”;
※ Secure 属性を付与するため、バックエンドがHTTPであっても、クライアントからはHTTPSで通信させることが前提だ。
—
4. まとめ：プロの現場の「掟」
最後に、一つだけ伝えておきたい。セキュリティは「設定して終わり」ではない。
1. Statefulな変更は全てトークンで守れ: SameSite=Lax はあくまで「二重の備え」だ。POST/PUT/DELETEといった破壊的なメソッドには、必ずランダムなCSRFトークンを要求せよ。
2. GETで状態変更をするな: 「IDを指定して削除」のようなAPIをGETで作るな。これはCSRFだけでなく、ブラウザのプリフェッチやログ漏洩のリスクにも直結する。
3. WAFは最後の砦: AWS WAFなどのマネージドサービスで「CSRF保護ルール」を有効にするのは有効だが、それは「開発の不備をインフラが補填している」状態であることを忘れてはならない。
コードを書くとき、常に「ブラウザはユーザーの意思を無視して勝手にリクエストを投げられる」という前提で設計してほしい。その疑い深さこそが、最強の防御力になるんだ。現場からは以上だ。
コメント