「ログインしてるから大丈夫」は命取り。CSRFと再認証の泥臭い現実
現場のエンジニア諸君、お疲れ様。今日もコードと格闘していることと思う。
さて、今回は「CSRF（クロスサイト・リクエスト・フォージェリ）対策」の話だ。教科書には「Anti-CSRFトークンを埋め込めば万全」と書いてあるだろう。確かにその通りだ。だが、俺が現場で見てきた「本当にヤバいインシデント」の多くは、トークンが突破されたわけではなく、「ログイン済み」という状態を悪用されたケースだ。
特に送金、パスワード変更、権限昇格といった「クリティカルな操作」において、トークンだけで済ませるのは、玄関の鍵はかけているが、金庫の扉を開けっ放しにしているようなものだ。
なぜ「再認証（パスワード再入力）」が最強の防壁なのか
CSRFの攻撃者は、ターゲットのセッションを乗っ取ろうとはしない。あくまで「ターゲットのブラウザを操り、本人の意思とは無関係にリクエストを投げさせる」だけだ。
例えば、攻撃者が仕掛けた罠サイトにアクセスした瞬間、ユーザーのブラウザから銀行口座の送金リクエストが飛ぶ。このとき、セッションは有効であり、CSRFトークンさえ合致していればサーバーは「ユーザー本人の意思による操作」だと信じ込んでしまう。
ここで「パスワードの再入力」というハードルがあればどうなるか？ 攻撃者はユーザーのパスワードを知らない。結果、攻撃はそこで物理的にストップする。「トークンは自動化できるが、ユーザーの記憶（パスワード）は自動化できない」。これが再認証を実装すべき最大の理由だ。
PoC：攻撃者は「隠れたフォーム」で何をしているか
攻撃者は非常にシンプルだ。ターゲットがログイン中の状態で、以下のような罠ページを閲覧させるだけだ。
もし、このリクエストの裏側で「パスワード再確認」が実装されていれば、サーバー側は password パラメータの欠如を検知し、送金処理を拒否できる。
実践：セキュアな実装（Python/Flaskの例）
「面倒くさい」という声が聞こえてきそうだが、実装はシンプルだ。重要な操作の前には、セッションに「直近の認証日時」を保持し、一定時間を過ぎていれば再認証を求める設計にする。
from flask import session, request, abort
import time
クリティカルな操作を行うデコレータ
def require_reauth(f):
def wrapper(args, kwargs):
last_auth = session.get(‘last_auth_time’, 0)
# 最後にパスワードを確認してから5分以内かチェック
if time.time() – last_auth > 300:
# 認証が必要な場合は専用ページへリダイレクト
return redirect_to_reauth_page()
return f(args, kwargs)
return wrapper
@app.route(‘/transfer’, methods=[‘POST’])
@require_reauth
def transfer():
# ここで初めて送金処理を行う
execute_transfer(request.form)
return “完了”
現場で「やらかさない」ためのTips
1. パスワード確認フォームには必ずAnti-CSRFトークンを入れる
再認証画面自体がCSRF攻撃の対象にならないよう、そこにもトークンは必須だ。
2. 「リダイレクト先」をURLパラメータで持たせる
再認証完了後に、ユーザーが元々行いたかった操作（送金など）へスムーズに戻れるよう、?next=/transfer のような設計にするとUXを損なわない。
3. パスワード確認用APIは「認証のみ」に徹する
パスワード確認APIに「送金機能」を混ぜるな。APIの責務は単一にするのが鉄則だ。
最後に：セキュリティは「多層」で考えるもの
WAFでCSRF攻撃をブロックすることも重要だが、WAFは「設定漏れ」や「未知のバイパス手法」に弱い。だからこそ、アプリケーションのビジネスロジック内に、今回紹介したような「ユーザーの意図を再確認するロジック」を埋め込んでおく必要がある。
「便利さ」と「安全性」のトレードオフで悩む局面は多いだろう。だが、送金や設定変更のような「後戻りできない操作」に限っては、迷わず再認証を要求すべきだ。それが、君が担当するアプリケーションを守り、ひいては君自身のキャリアを守ることにも繋がる。
次回のコードレビューで、誰かが「クリティカルな操作」を実装していたら、こう聞いてやってくれ。「これ、攻撃者に勝手にポチられたらどうするの？」と。
現場からは以上だ。また次の戦場で会おう。
コメント