【入門編】 OAuth 2.0におけるリダイレクトURIの厳密なホワイトリスト管理 – 暗号理論・認証基盤 & エンドポイントセキュリティ防御ガイド

こんにちは！Webアプリの開発や認証基盤の仕組みに触れ始めたばかりの新人エンジニアの皆さん、日々の開発本当にお疲れ様です。

セキュリティの世界へようこそ！「OAuth 2.0」や「認可コード」といった言葉、最初はなんだか呪文のように聞こえて難しく感じますよね。「なんだか大変そう…」と身構えてしまうかもしれませんが、一歩ずつ身近な例えから紐解いていけば、必ず「なるほど！」と腑に落ちる瞬間がやってきます。

今回は、OAuth 2.0の仕組みの中でも、特に油断すると大変なことになってしまう「リダイレクトURIの厳密なホワイトリスト管理」について、一緒に優しく学んでいきましょう！

—

1. 家の鍵で例える「OAuth 2.0」と「リダイレクトURI」

まずは、セキュリティを考えるときの定番、「合鍵」の例えからスタートします。

皆さんが、友だちに自宅の掃除や荷物の受け取りをお願いしたとします。このとき、毎回あなた自身のマスターキーを渡したり、合庁の暗証番号を直接教えたりするのはちょっと怖いですよね。「代わりにやっておいて」と頼む代わりに、一時的に「荷物を受け取る権利」だけを書いた「お手伝い証明書（アクセストークン）」を渡す仕組み、これが OAuth 2.0 の考え方です。

そして、この「お手伝い証明書」を、頼んだ相手（外部の便利なアプリなど）へ安全に渡すための「送り先の住所」が、今回主役になる「リダイレクトURI」です。

もし、この送り先の住所がテキトーだったり、悪意ある泥棒に書き換えられてしまったりしたらどうなるでしょうか？あなたが「はい、これをお手伝いさんに渡してね」と差し出した大切な証明書が、そっくりそのまま泥棒の手に渡ってしまうことになります。これが、リダイレクトURIの管理をミスしたときに起こる恐ろしいシナリオです。

—

2. 攻撃者が狙う盲点：オープンリダイレクタと認可コード泥棒

OAuth 2.0を使ったログイン画面（例えば「Googleでログイン」や「GitHubでログイン」など）で見かける、あのリダイレクトの裏側を覗いてみましょう。

認証サーバー（GoogleやGitHubなど）は、ユーザーが無事にログインを終えると、次のようにアプリへ戻そうとします。

https://your-app.com/callback?code=super_secret_auth_code_12345

この code= に続く文字列が「認可コード」と呼ばれるもので、これが分かればアプリにログインできてしまう超重要アイテムです。

ここで、もしアプリケーション側に「オープンリダイレクタ脆弱性」という、どこへでも自由にジャンプできてしまうお茶目な穴があったとします。攻撃者は、次のような巧妙な罠のリンクを作ります。

https://your-app.com/login?redirect=https://evil-attacker.com/steal

もし、認証サーバー側が「https://your-app.com から始まるから、まあ大丈夫でしょ！」と、URIのチェックを甘く（部分一致や前方一致などで）緩くしていたらどうなるでしょうか？

認証サーバーは、ユーザーの大切な認可コードを、なんと悪意ある攻撃者のサーバー（evil-attacker.com）へ送り届けてしまうのです！これが、オープンリダイレクタを悪用した認可コードの横取り（漏洩）のメカニズムです。

—

3. 完全一致によるホワイトリスト管理で鉄壁の守りを作る

こうした脅威を防ぐために、私たち開発者が絶対に守らなければならない鉄則が、「リダイレクトURIの完全一致（Exact Match）によるホワイトリスト管理」です。

「前方一致」や「ドメイン部分一致」なんていう妥協は、セキュリティの世界ではご法度です。

× ゆるゆるな判定: https://*.your-app.com （サブドメインならどこでもOKにしちゃう）
〇厳格な判定: https://app.your-app.com/auth/callback （1文字たりとも完全一致するものだけを許可する）

認証サーバー側の設定でも、アプリ側からの登録でも、この「完全一致」を徹底することが、泥棒の入り込む隙を完全に断つ最高の防犯対策になります。

—

4. 【実務向け】安全な実装と設定のサンプル

それでは、実際にコードや設定を行う際のイメージを見ていきましょう。今回はPHPを使った簡単なコールバック受け取りのサンプルと、ホワイトリストの検証ロジックの例をご紹介します。

バックエンド側（PHP）の検証ロジック例

アプリケーション側でも、受け取ったリダイレクト先やリクエストパラメータが正当なものであるかを二重で確認する姿勢がプロとしての腕の見せ所です。

<?php
// 事前に安全性が確認され、データベースや設定ファイルに登録された「ホワイトリスト」のリスト
$allowed_redirect_uris = [
    'https://app.your-app.com/auth/callback',
    'https://app.your-app.com/settings/callback'
];

// ユーザーから送られてきた、または認証サーバーへ指定するリダイレクトURI
$client_redirect_uri = $_GET['redirect_uri'] ?? '';

/**
 * リダイレクトURIがホワイトリストに完全に一致するかを厳密に検証する関数
 * 
 * @param string $uri 検証対象のURI
 * @param array $whitelist 許可されたURIの配列
 * @return bool 一致する場合はtrue、そうでない場合はfalse
 */
function validateRedirectUri(string $uri, array $whitelist): bool {
    // 曖昧な部分一致やワイルドカード判定は避け、厳密な「完全一致（===）」を使用します
    return in_array($uri, $whitelist, true);
}

// 検証の実行
if (!validateRedirectUri($client_redirect_uri, $allowed_redirect_uris)) {
    // 攻撃の可能性または設定ミスがあるため、処理を即座に中断する
    header("HTTP/1.1 400 Bad Request");
    echo "エラー: 不正なリダイレクトURIが指定されました。セキュリティポリシーにより処理を中断します。";
    exit;
}

// --- ここから先の安全な処理 ---
// 例: 認可コードの受け取り処理やセッションの発行など
echo "認証成功！安全なセッションを開始します。";
?>

このように、配列との比較に in_array($uri, $whitelist, true) のように厳密な型チェック（第三引数に true を指定）を組み込み、曖昧な正規表現や文字列の部分一致関数（strposなど）を安易に使わないことが、セキュリティインシデントを防ぐ大きなカギになります。

—

5. まとめ：一歩ずつ、確実なセキュリティを身につけようい

いかがでしたでしょうか？
「OAuth 2.0におけるリダイレクトURIの厳密なホワイトリスト管理」と言われると難しそうですが、要するに「お手紙の大切な送り先は、一言一句間違えてはいけないし、怪しい宛先には絶対に届けない」という、ごく当たり前の防犯意識をコードやシステム設定に落とし込む作業に他なりません。

新人エンジニアの皆さんも、日々の開発の中で「このURLのチェック、もしかして緩くなっていないかな？」と立ち止まる視点（セキュリティマインド）を少しずつ育てていってくださいね。その小さな気づきが、未来の重大な情報漏洩を防ぐヒーローの第一歩になります。

それでは、また次回のセキュリティ解説でお会いしましょう！安全で楽しい開発ライフを！