【テクニカル・上級編】クロスサイトリクエストフォージェリ(CSRF)の仕組みとトークン検証の実装 – アプリケーションセキュリティ & 安全な開発防御ガイド

クロスサイトリクエストフォージェリ (CSRF) の深層：古典的脅威の現代的防御戦略

世界中のサイバー空間で日々繰り広げられる攻防の最前線に身を置く我々にとって、新たな脆弱性の発見は常に刺激的であり、同時に脅威の進化を肌で感じる瞬間でもあります。しかし、その一方で、Webアプリケーションセキュリティの古典とも言える脆弱性が、いまだに多くのシステムで見過ごされ、甚大な被害を引き起こしている現実も直視しなければなりません。今回、我々が深く掘り下げるのは、その代表格の一つであるクロスサイトリクエストフォージェリ (CSRF) です。

「CSRFなど、もはや基本中の基本ではないか」と考える方もいるかもしれません。しかし、その「基本」の裏側には、HTTPプロトコルの設計思想、ブラウザのセキュリティモデル、そして現代の複雑なWebアプリケーションにおけるセッション管理の盲点といった、多層的な理解が求められる奥深さがあります。単なるチェックリスト項目として片付けるのではなく、攻撃者が狙う「見えざる手」の正体を暴き、最高峰の防御戦略を構築するための知見を共有しましょう。

CSRFのメカニズム再考：なぜブラウザは「意図しない」リクエストを送るのか？

CSRF攻撃は、認証済みのユーザーが、意図しないリクエストをWebアプリケーションに対して実行させられる脆弱性です。その本質は、HTTPプロトコルとその上で動作するブラウザの「性善説」とも言える挙動に根ざしています。

HTTPプロトコルの「性善説」とCookieの自動送信

HTTPはステートレスなプロトコルであり、各リクエストは独立しています。この「状態を持たない」特性を補い、ユーザーのセッションを維持するためにCookieが利用されます。ブラウザは、同一オリジンへのリクエストにおいて、そのオリジンに関連付けられたCookieを自動的に添付して送信します。ここがCSRFの攻撃経路の出発点となります。

攻撃者は、ユーザーが既にログインしている正規のサイト（例: ネットバンキング）と、悪意のあるサイト（例: 罠サイト）を巧みに利用します。

1. ユーザーが正規サイトにログイン: 認証に成功し、セッションIDを含むCookieがブラウザに保存されます。
2. ユーザーが罠サイトを訪問: 罠サイトには、正規サイトに対する特定の操作（例: 送金、パスワード変更）を意図したHTTPリクエストを生成するHTML要素（例: 、

）が埋め込まれています。
3. ブラウザが罠サイトの指示に従いリクエストを送信: このリクエストは正規サイトへ向けられ、ブラウザは自動的に正規サイトのセッションCookieを添付します。
4. 正規サイトはリクエストを正当なものと判断: 有効なセッションCookieが添付されているため、正規サイトはユーザー自身からのリクエストであると誤認し、操作を実行してしまいます。

この一連の流れにおいて、ブラウザはユーザーの意図を問わず、Cookieのルールに従って行動します。これは、Webの初期設計における、異なるオリジン間のリソース共有に関するセキュリティモデル（Same-Origin Policy: SOP）が、リソースの「読み取り」を制限する一方で、リソースの「書き込み」（状態変更）については比較的緩やかだった名残とも言えます。SOPはJavaScriptによるクロスオリジン読み取りを厳しく制限しますが、HTMLタグ（,