【入門編】 OAuth 2.0のRedirect URI検証不備によるトークン流出 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

OAuth 2.0の「リダイレクト先」にご用心！トークンを盗まれないための防犯対策

こんにちは！セキュリティの世界へようこそ。今日は、Webサービスでよく見かける「Googleでログイン」や「SNS連携」の裏側で動いている「OAuth 2.0（オーオース）」という仕組みについて、少しだけディープな防犯のお話をします。

「連携ボタンを押すだけだし、簡単で安全でしょ？」と思われがちですが、実はここ、攻撃者が一番狙いたがる「ドアの鍵の隙間」が存在するんです。今日は、泥棒がどうやってトークン（通行証）を盗み出そうとするのか、その手口を一緒に紐解いていきましょう。

—

1. OAuth 2.0は「ホテルのチェックイン」と同じ

まず、OAuth 2.0の仕組みを身近な例で考えてみましょう。

あなたが高級ホテル（サービスA）に泊まりたいとします。でも、身分証を出すのが面倒なので、「隣の信頼できる銀行（サービスB）」で発行されたデジタル身分証を使ってチェックインすることにしました。

1. あなた： 「サービスAさん、ログインしたいです」
2. サービスA： 「じゃあ、あなたの信頼できる銀行（サービスB）で認証してきて。終わったらここに戻ってきてね」
3. あなた： （銀行で認証後）「サービスAさん、戻ってきました！」

この「戻ってくる場所」がリダイレクトURIです。ここがもし、泥棒が用意した「偽の受付カウンター」だったらどうなるでしょうか？

—

2. 泥棒の手口：リダイレクトURIを「すり替える」

攻撃者は、サービスAに対して「認証が終わったら、私のサイト（https://attacker.com）に情報を送って！」と細工したURLを投げかけます。

もしサービスAが「戻ってくる場所」を厳密にチェックしていないと、あなたの大切な「アクセストークン（通行証）」を、攻撃者のサーバーへ直接送り届けてしまうのです。

これが「リダイレクトURI検証不備」という脆弱性です。

なぜ「ワイルドカード」が危険なの？

よくある間違いが、リダイレクト先の指定にワイルドカード（*）を使ってしまうこと。

https://myapp.com/* と設定すると……
攻撃者は https://myapp.com.attacker.com のような似たドメインを用意し、ここへトークンを誘導します。

これは、家の鍵を「近所の人なら誰でも開けていいよ」と公言しているようなもの。非常に危険ですよね。

—

3. どうやって防ぐ？「完全一致」が鉄則です

対策はシンプルです。「信頼できる場所リスト」を、一文字の誤差もなく厳密に登録すること。これに尽きます。

悪い設定例（やめましょう！）

設定ファイルやデータベースで、以下のように曖昧な指定をしてはいけません。

# ダメな例：ワイルドカードの使用
redirect_uri = https://myapp.com/*

良い設定例（推奨）

「ここにしか戻さない！」と、フルパスで厳密に指定します。

# 良い例：完全一致での指定
redirect_uri = https://myapp.com/callback/oauth2

—

4. 実務で役立つ「防御ヘッダー」の知識

リダイレクト先を絞るだけでなく、Webブラウザ自体に「ここ以外の通信は許可しないで！」と命令する防犯装置もあります。それがCSP（Content Security Policy）です。

もしもの時のために、以下のヘッダーをサーバーの応答に含めておきましょう。

# HTTPレスポンスヘッダーの例
Content-Security-Policy: default-src 'self'; connect-src 'self' https://trusted-api.com;

default-src 'self'：自分のサイト以外の通信を基本ブロックします。
connect-src：API通信を許可する先を限定します。

泥棒があなたのサイトに不正なスクリプトを埋め込もうとしても、このヘッダーがあればブラウザが「許可されていない通信だ！」と止めてくれるのです。

—

まとめ：今日からできる一歩

1. リダイレクトURIは「完全一致」で登録する： 曖昧な設定は、泥棒への招待状です。
2. 動的なリダイレクトを避ける： ユーザーがURLの一部を操作してリダイレクト先を変えられるような実装は避けましょう。
3. CSPヘッダーを導入する： 多重の防犯ロックをかけましょう。

セキュリティは、一度設定して終わりではありません。でも、こうして「なぜダメなのか」という理由を知るだけで、コードを見る目がガラリと変わるはずです。

最初は難しく感じるかもしれませんが、まずは「自分のサービスに戻ってくる場所は、本当にここだけで合っているかな？」と確認することから始めてみてくださいね。一歩ずつ、強固なサービスを作っていきましょう！