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

OAuth 2.0 リダイレクトURIの「甘い管理」が招く地獄：攻撃者の視点と防御の鉄則

現場でコードを叩いていると、「とりあえず動けばいい」という妥協が、数ヶ月後に致命的なインシデントとなって返ってくる場面に何度も立ち会ってきた。OAuth 2.0の redirect_uri は、まさにその典型だ。

「開発環境と本番で設定を変えるのが面倒だから」「サブドメインがたくさんあるから」といって、リダイレクト先をワイルドカード（*）で許可したり、部分一致で済ませたりしていないだろうか？その1行のコードが、攻撃者にとっての「黄金のチケット」になることを、まずは理解してほしい。

なぜ「完全一致」以外は悪なのか

攻撃者が狙うのは、認可コード（Authorization Code）の横取りだ。

もしリダイレクトURIが https://example.com/callback?* のように前方一致で許可されていると、攻撃者は https://example.com/callback.attacker.com という巧妙なURLを仕込み、ユーザーを誘導する。ユーザーが認可ボタンを押した瞬間、本来のクライアントではなく攻撃者のサーバーに認可コードが送信されてしまう。これが「オープンリダイレクタ脆弱性」を利用した典型的な攻撃フローだ。

攻撃者はそのコードを奪い、正規のクライアントになりすましてアクセストークンを交換する。一度トークンを奪われれば、ユーザーの個人情報や権限へのアクセスは「やりたい放題」になる。

実務で求められる防御の解像度

防御の鉄則はただ一つ、「サーバーサイドでの完全一致検証」だ。クライアントから送られてきた redirect_uri と、事前にDBや設定ファイルに登録された「正解」を、一文字の誤差もなく比較する。

実装サンプル：PHPによるセキュアな検証ロジック

多くのエンジニアが犯すミスは、strpos や正規表現でバリデーションを行おうとすることだ。これらは実装漏れを誘発する。以下のコードのように、ホワイトリストを配列で持ち、厳格に比較する実装を徹底してほしい。

<?php
/**
 * セキュアなリダイレクトURI検証関数
 */
function is_valid_redirect_uri(string $request_uri): bool {
    // 許可されたリダイレクトURIを「完全一致」でホワイトリスト化する
    // 決してワイルドカードや動的な正規表現を使わないこと
    $whitelist = [
        'https://app.example.com/oauth/callback',
        'https://app.example.com/oauth/callback-v2'
    ];

    // URIの正規化（末尾のスラッシュの有無やエンコードを揃える）
    $normalized_uri = filter_var($request_uri, FILTER_SANITIZE_URL);

    // in_arrayの第3引数にtrueを指定し、型も含めて厳密に比較する
    return in_array($normalized_uri, $whitelist, true);
}

// 利用例
$provided_uri = $_GET['redirect_uri'] ?? '';
if (!is_valid_redirect_uri($provided_uri)) {
    // ログに記録し、攻撃の兆候として処理を中断する
    error_log("不正なリダイレクトURIが検出されました: " . $provided_uri);
    http_response_code(400);
    exit('Invalid Redirect URI');
}
?>

インフラ層での二重防壁：Nginx設定による保護

アプリケーションコードだけでなく、インフラ層でもガードを固めるのがプロの流儀だ。Nginxなどのリバースプロキシで、怪しいリクエストをフロントゲートで遮断する。

# Nginx設定例：許可されていないパラメータを含むリクエストを拒否
location /oauth/authorize {
    # クエリパラメータに悪意のある文字が含まれていないかチェックする例
    # redirect_uri が許可されたドメイン以外を含んでいないか、Mapディレクティブで制御するのも有効
    if ($arg_redirect_uri !~* "^https://app\.example\.com/oauth/callback$") {
        return 403;
    }
    
    proxy_pass http://backend_app;
}

現場のエンジニアへ伝えたい「泥臭い知見」

最後に、一つだけ覚えておいてほしい。セキュリティ設定は「一度作って終わり」ではない。

1. 認可サーバー側での強制: 認可サーバー（Keycloak, Auth0, AWS Cognitoなど）の設定画面で、redirect_uri を必ず「完全一致（Exact Match）」に設定すること。これを疎かにしてアプリケーション側だけで対策しようとするのは、鍵をかけずに窓を閉めるようなものだ。
2. ログ監視の徹底: 不正な redirect_uri が送られてきたら、即座にアラートを飛ばすこと。これは攻撃者が「このシステムに脆弱性がないか」をスキャンしているサインだ。この段階で攻撃者を特定できれば、インシデントは未然に防げる。
3. Stateパラメータの併用: リダイレクトURIの保護とセットで、必ず state パラメータを使い、CSRF攻撃を防ぐこと。state は推測不可能な乱数であり、リクエストとレスポンスを紐付ける唯一の証拠になる。

セキュリティは、派手なハッキング手法を防ぐことよりも、こうした「退屈で地味な検証」をどれだけ厳格に積み重ねられるかで決まる。明日から自分のシステムの redirect_uri 設定を見直し、ホワイトリストが「完全一致」になっているか、確認することをお勧めする。

それが、あなたのサービスを守るための、最もコストパフォーマンスの高い一歩だ。