なぜその「鍵」は丸見えなの？CSRFトークン漏洩の恐怖と、泥棒を追い出す防犯術
こんにちは！セキュリティの世界へようこそ。今日は、Webアプリ開発において「これだけはやっちゃダメ！」という、ある致命的なミスについてお話しします。
皆さんは「CSRFトークン」という言葉を聞いたことはありますか？難しそうに聞こえるかもしれませんが、実はとってもシンプルな「身分証明書」のようなものなんです。今日は、この大切な身分証明書を「うっかり外に落としてしまう」という、エンジニアがやりがちな大失態と、その防ぎ方について、身近な例えを交えてお話ししますね。
—
CSRFトークンって、何なの？
家を想像してみてください。玄関の鍵（ログインパスワード）を開けて中に入った後、誰かが勝手に部屋の模様替えをしたり、勝手に荷物を運び出したりしたら困りますよね。
Webの世界では、悪意ある第三者があなたの代わりに勝手に操作を行う「CSRF（クロスサイト・リクエスト・フォージェリ）」という攻撃があります。これを防ぐために、Webサイトは「これは本人からの正規のリクエストですよ」と証明する「CSRFトークン」という、いわば「一時的な通行手形」を発行します。
このトークンがないと、どんなに正しい操作をしようとしても、システムは「怪しい人だな」と判断して門前払いしてくれる。これが防犯の仕組みです。
—
「URLにトークンを含める」という大罪
さて、ここで問題です。この大切な「通行手形」、どこに忍ばせておくのが安全でしょうか？
一番やってはいけないのが、「URLのパラメータに直接書いてしまうこと」です。
例えば、こんなURLです。
https://example.com/update-profile?user_id=123&token=abc123xyz...
これ、泥棒に「これが僕の家の合鍵です！」と見せびらかしながら歩いているのと同じなんです。なぜダメなのか、理由は二つあります。
1. ブラウザの履歴やログに残る： パソコンの閲覧履歴や、サーバーのアクセスログにトークンが丸ごと残ります。誰かがあなたのパソコンを覗き見れば、そのトークンは盗み放題です。
2. Refererヘッダーでの漏洩： これが今日一番伝えたいポイントです。
—
Refererヘッダーという「足跡」の罠
Webブラウザは、あるページから別のページへ移動するとき、移動元の情報を「Referer（リファラー）」というヘッダーに載せて送りつけます。「さっきまでここにいたよ」という足跡ですね。
もし、あなたのサイトのURLにトークンが含まれていたらどうなるでしょう？
ユーザーがそのページから外部のサイト（例えば広告や、悪意あるサイトへのリンク）へ移動した瞬間、移動先のサイトの管理者に、あなたのトークンが筒抜けになります。
「あ、このURLにトークンが載ってる！ラッキー、これを使ってユーザーになりすまして操作してやろう」という具合に、泥棒を招き入れてしまうわけです。
—
どうすれば安全に守れるの？
では、どうすればいいのでしょうか。対策は非常にシンプルで強力です。一歩ずつ学んでいきましょう！
1. トークンは「POST」で隠す
URL（GET）ではなく、HTTPのPOSTリクエストの「ボディ」にトークンを含めましょう。これなら、履歴にもログにも、Refererヘッダーにも載ることはありません。
【HTMLの例】
2. Referrer Policyで足跡を消す
万が一、外部へのリンクを貼る必要がある場合や、情報の漏洩を最小限にしたい場合は、HTMLのヘッダーで「移動先には情報を渡さないで！」と指示を出せます。
【HTMLのmetaタグによる設定】
これを設定しておけば、もしトークンをURLに含めるような不測の事態があっても、Refererヘッダーの中身は空っぽになるため、外部に漏れるリスクを劇的に下げることができます。
—
まとめ：セキュリティは「情報の扱い」から
今日の教訓をまとめます。
- CSRFトークンは「命の次に大事な通行手形」と心得る。
- URLパラメータ（GET）に重要な情報を載せない。 泥棒に鍵を見せびらかすようなものです。
- Refererヘッダーの性質を知る。 便利な機能ですが、油断すると情報を外部に垂れ流す窓口になります。
セキュリティ対策というと、難しい暗号化やファイアウォールをイメージしがちですが、実はこういった「データの通り道」を意識するだけで、防げる攻撃は山ほどあります。
最初は難しく感じるかもしれませんが、まずは「自分の書いたコードが、どこで誰に見られるか？」を想像する癖をつけてみてください。その想像力が、あなたを世界で一番頼りになるエンジニアに育ててくれるはずですよ。
それでは、また次のセキュリティ・レッスンでお会いしましょう！
コメント