CSRF（Cross-Site Request Forgery、クロスサイトリクエストフォージェリ）は、標的のWebサイトに既にログイン済みの利用者を、別の罠サイトから誘導し、本人が意図しない送金・設定変更・退会といった操作を実行させる攻撃です。2001年にネットワーク技術者Peter Watkins氏がBugtraqメーリングリストに投稿した文書で「Cross-Site Request Forgeries」という呼称が広まり、以来Webアプリケーション設計の必修課題となりました。ブラウザがCookieを自動付与する性質を逆手に取るシンプルな攻撃ですが、被害は依然として後を絶ちません。
この記事の目次
- 罠ページから正規サイトへ自動送信
- Webメールから金融機関までの被害例
- トークン・SameSite・参照元の合わせ技
- XSS・クリックジャックとの差
- まとめ
罠ページから正規サイトへ自動送信
CSRFの基本シナリオは「被害者がオンラインバンクやSNSにログインしたまま、別のブラウザタブで攻撃者の用意したページを開く」というだけで成立します。罠ページにはform要素や非表示img要素、JavaScriptのfetchなどで、銀行サイトの送金APIに向けた偽のリクエストが仕込まれています。ブラウザは同一ドメインへのリクエストにCookieを自動付与するため、被害者本人のセッションIDがそのまま添えられ、銀行のサーバから見れば本人の操作と区別できません。
リクエストはGETでもPOSTでも成立し得ます。古典的にはimgタグでGETを呼び出す手口が知られていますが、現代のサイトは状態変更をPOSTに揃えていることが多いため、formの自動submitやXMLHttpRequestを使った手法が主流です。サブミットボタンを画面外に置く、ページ表示と同時にJavaScriptでクリックさせるなど、被害者に違和感を与えない演出が組み合わされ、SNS投稿、メール設定変更、退会、商品購入など多種多様な操作が「本人名義で実行された」事故として発生します。
Webメールから金融機関までの被害例
CSRFは派手なゼロデイと違って静かに被害をもたらすため事件として公表されにくいのですが、公表されている事案でも2008年のNetflix、2008年のGmailの一部機能、2012年のeBay、2017年のGoBank、そして家庭用ルーターのDNS設定をCSRFで書き換える事件など、幅広いサービスが対象になってきました。特にWebメールでの「転送先設定の書き換え」と、ホームルーターでの「DNS書き換え」は、本人が気付かない間に長期的な情報漏えいや別の攻撃の足場形成につながる悪質な事例です。
Peter Watkins氏が2001年のBugtraq投稿で命名する前から類似の問題は議論されていましたが、彼の文書「Cross-Site Request Forgeries（CSRF/XSRF）」がきっかけで概念が一気に普及し、OWASPは2003年の初版Top10にこの問題を盛り込みました。その後2007年版ではTop10第5位として独立カテゴリ化され、Webフレームワーク各種が標準でCSRF対策を持つようになる流れが加速します。現在ではSameSite Cookieやフレームワーク内蔵トークンが普及し、新規開発で起こしにくい脆弱性へと変化しました。
トークン・SameSite・参照元の合わせ技
CSRF対策の本命は、サーバ側でランダム生成したトークンをフォームに埋め込み、送られてきたリクエストに同じ値が含まれているかを照合する「同期トークン方式」です。Django、Ruby on Rails、Laravel、ASP.NET、Spring SecurityなどがこのCSRFトークンを標準装備しており、テンプレート側でタグを書くだけでhiddenフィールドが自動挿入されます。罠サイトはトークンを推測できないため、リクエストがサーバの照合で弾かれる仕組みです。
ブラウザ側ではSameSite Cookie属性が決定打になりました。ChromeはSameSite=Laxを標準に格上げし、認証Cookieがクロスサイトリクエストに自動付与されなくなったため、古典的なform自動submit型のCSRFは大きく削がれました。それでも完全ではないため、Originヘッダ・Refererヘッダの検証、重要操作（パスワード変更・送金など）での再認証、状態変更はGETでなくPOSTに統一する、といった多層防御を組み合わせます。アプリ・ブラウザ・運用ルールの三段構えで現代的なCSRFリスクは抑え込めます。
XSS・クリックジャックとの差
CSRFはしばしばXSSと混同されますが、両者の本質は全く異なります。XSSは攻撃者のスクリプトを正規サイト上で実行させる攻撃で、閲覧者の権限内で何でも自由にできてしまう強力な脆弱性です。対するCSRFはスクリプト実行を必要とせず、被害者ブラウザが「自動的にCookieを付けて送ってくれる」という標準挙動だけで成立します。そのため対策の焦点も、XSSが出力エスケープなのに対しCSRFはトークン照合と来訪元検証に置かれます。
クリックジャッキングは透明iframeで正規サイトを覆って利用者の意図しない操作を誘発する別系統で、リクエスト自体は被害者のクリック動作で生成されるためCSRFよりはユーザー操作が伴います。セッションFixationは「攻撃者が用意した既知のセッションIDで被害者にログインさせる」攻撃で、リプレイ攻撃は盗聴したリクエストをそのまま再送するものです。いずれも「認証セッションを悪用する」という点でCSRFと近縁に見えますが、実装上の鍵は微妙に異なり、それぞれに合った防御策を区別して実装する必要があります。
まとめ
CSRFはブラウザがCookieを自動送信する仕様の隙を突く、Web黎明期から残る古典的攻撃です。フレームワーク標準のトークン照合、SameSite Cookie、重要操作の再認証を組み合わせれば、新規開発で踏み抜くケースはほぼ防げます。「認証済みであることだけを信用しない」という発想を、設計の初手に置くことが鍵です。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント