【実務・中級編】 OAuth 2.0のOpen Redirect脆弱性によるトークン漏洩 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

お疲れ。今日のインシデントレビューを始めるぞ。

先週、うちのクライアントのモバイルアプリ連携基盤で、OAuth 2.0の認可コードフローを狙ったヒヤリハット事案があった。攻撃者はアプリの利便性を逆手に取り、ユーザーのアクセストークンを綺麗に自分の管理サーバーへと持ち出そうとしていたんだ。幸い、APIゲートウェイのログ監視とWAFの異常検知で水際防衛できたが、一歩間違えば数百万人のセッションが乗っ取られる大惨事になっていた。

OAuth 2.0やOIDC（OpenID Connect）は、今やモダンなWebアプリケーションやAPI連携のインフラストラクチャそのものだ。しかし、「とりあえずライブラリを入れて動かした」という実装現場ほど、リダイレクトURIのバリデーション不備という致命的な爆弾を抱えている。

今回は、レッドチームの視点からこの攻撃がどのように成立し、アクセストークンが秒速で抜き取られるのかという「エクスプロイトの現実」を叩き込んだ上で、明日からプロダクション環境に投入できる決定版の防御コードを共有する。後輩の君たちには、綺麗ごとのセキュリティではなく、現場で生き残るための実装を叩き込んでおく。

—

1. なぜOAuth 2.0の「リダイレクトURI」は魔窟なのか？

OAuth 2.0の認可フローにおいて、認可サーバー（IdP）はユーザーの認証・同意を得た後、発行した認可コード（Authorization Code）やアクセストークンを、クライアントアプリケーション側へ送り返す必要がある。その送り先を指定するのが redirect_uri パラメータだ。

攻撃者の狙いは単純明快。「正規のクライアントアプリのふりをして、被害者を騙して不正なリダイレクト先を指定させ、そこにトークンをホップ・ステップ・ジャンプさせる」ことだ。

攻撃シーケンスのリアル

1. フィッシング・罠の設置: 攻撃者は、正規のOAuth認可リクエストを含んだ巧妙なリンク（またはQRコード等）を被害者に踏ませる。
2. 緩いバリデーションの突破: 認可サーバー側の redirect_uri の検証ロジックが甘く、前方一致やドメインの部分一致（例: https://example.com.attacker.com や、オープンリダイレクターの併用）を許容してしまっている。
3. トークンの強奪: 被害者が被害者自身のブラウザで正規のIdPにログインしアクセス権を承認すると、IdPはトークン（または認可コード）を引っさげて、攻撃者の指定した不正なURLへリダイレクトを実行する。
4. アカウント乗っ取り: 攻撃者のサーバー（例: https://attacker.com/steal?code=XXX）のアクセスログやスクリプトが、その機微情報を一網打尽に回収する。

ここで重要なのは、「被害者自身が正規のサービスで認証しているため、IdP側からは正規のトラフィックに見えてしまう」という点だ。WAFのシグネチャ単体では、この文脈の不正を見抜くのは極めて困難を極める。

—

2. 攻撃者の視点：脆弱なバリデーションの裏をかくPoC

世の中の甘い実装でよく見られるのが、正規表現や文字列の部分一致による redirect_uri のチェックだ。「https://example.com で始まっていればOK」といった雑なコードを書いている現場は、今すぐ冷や汗をかいた方がいい。

以下は、攻撃者が実際に仕込むエクスプロイトの概念的なリクエストと、それを受け止める悪意あるスクリプトの構造だ。

脆弱なバリデーションの例（よくある誤り）

// 【危険な実装例】Node.js / Express での雑な文字列前方一致チェック
app.get('/oauth/authorize', (req, res) => {
    const redirectUri = req.query.redirect_uri;
    const allowedBase = "https://app.example.com";

    // ❌ 脆弱性: "https://app.example.com.hacker.evil/" も通ってしまう！
    if (redirectUri && redirectUri.startsWith(allowedBase)) {
        // 処理を継続...
    }
});

この実装に対し、攻撃者は redirect_uri=https://app.example.com.evil-attacker.com/callback というパラメータをねじ込む。IdPのバリデーションをすり抜けた認可コードは、見事に攻撃者のサーバーへと直行するわけだ。

—

3. 【完全防御】実務で使えるセキュアな実装と設定

この脆弱性を根絶するための鉄則はたった一つ。「リダイレクトURIは、完全一致（Exact Match）のホワイトリスト方式で厳格に検証する」ことだ。部分一致やワイルドカードの乱用は、セキュリティ上の百害あって一利なしである。

ここからは、バックエンド（PHP）での堅牢なバリデーション実装と、Nginx側での追加の安全策を示す。コピペしてチームのコードレビュー基準にしてほしい。

実装サンプル①: PHPによる厳格な完全一致バリデーション

認可エンドポイントや、クライアントからのリダイレクトURIを受け取るモジュールでは、必ずあらかじめ登録された完全一致のホワイトリストと比較する。

<?php
/**
 * OAuth 2.0 リダイレクトURIの厳格な検証関数
 * 
 * @param string|null $inputUri ユーザーから送信されたリダイレクトURI
 * @param string $clientId クライアントID
 * @return string 検証済みの安全なURI、または例外をスロー
 * @throws Exception 不正なURIが検知された場合
 */
function validateAndGetRedirectUri(?string $inputUri, string $clientId): string {
    if (empty($inputUri)) {
        throw new \InvalidArgumentException("リダイレクトURIが指定されていません。");
    }

    // 本来はDBや設定ファイルからクライアントIDに対応する許可リストを取得する
    // 【重要】ワイルドカードや部分一致は一切使わず、登録された完全一致の配列を持つこと
    $allowedUriWhitelist = [
        'client_app_001' => [
            'https://app.example.com/callback',
            'https://app.example.com/oauth/redirect'
        ],
        'client_app_002' => [
            'https://portal.example.org/auth/cb'
        ]
    ];

    // クライアントIDの存在確認
    if (!isset($allowedUriWhitelist[$clientId])) {
        throw new \DomainException("無効なクライアントIDです。");
    }

    $clientWhitelist = $allowedUriWhitelist[$clientId];

    // 【核心】完全一致（Exact Match）による厳密な比較
    // parse_urlでパースして構造レベルで比較するアプローチがさらに堅牢
    $parsedInput = parse_url($inputUri);
    
    // スキームとホスト、パスの正規化（フラグメントや余分なスラッシュの排除）
    $normalizedInput = sprintf(
        '%s://%s%s',
        $parsedInput['scheme'] ?? '',
        $parsedInput['host'] ?? '',
        $parsedInput['path'] ?? ''
    );

    $isAllowed = false;
    foreach ($clientWhitelist as $whitelistedUri) {
        $parsedAllowed = parse_url($whitelistedUri);
        $normalizedAllowed = sprintf(
            '%s://%s%s',
            $parsedAllowed['scheme'] ?? '',
            $parsedAllowed['host'] ?? '',
            $parsedAllowed['path'] ?? ''
        );

        // 文字列としての完全一致を評価
        if (hash_equals($normalizedAllowed, $normalizedInput)) {
            $isAllowed = true;
            break;
        }
    }

    if (!$isAllowed) {
        // セキュリティインシデントとしてログに詳細を記録（IPやユーザーエージェントも一緒に）
        error_log(sprintf("[SECURITY ALERT] 不正なリダイレクトURIの検出: ClientID=%s, URI=%s", $clientId, $inputUri));
        throw new \SecurityException("指定されたリダイレクトURIは許可されていません。");
    }

    // クエリパラメータが含まれている場合の扱い（原則としてOAuth仕様では認可レスポンス時の付与を除き静的なURIを推奨）
    // 安全のため、入力された完全なURIを返す（ホワイトリストに登録されたもの、またはクエリの有無を厳密に制御）
    return $inputUri;
}

実装サンプル②: Nginxリバースプロキシ設定でのパラメータ保護

WebサーバーやAPIゲートウェイのレイヤーでも、怪しいリクエスト（特にオープンリダイレクターやURLエンコードを多用した難読化攻撃）を弾く設定を入れておくと多層防御として非常に効果的だ。

# Nginx 設定ファイルスニペット (nginx.conf / sites-available/default)

server {
    listen 443 ssl;
    server_name auth.example.com;

    # SSL/TLS設定は省略...

    location /oauth/authorize {
        # クエリパラメータに悪意のある文字（制御文字や二重エンコードなど）が含まれていないかチェック
        # 例: 不審なスキーム（javascript:, data: 等）のインジェクションをブロック
        if ($arg_redirect_uri ~* "(javascript:|data:|vbscript:|file:)Data") {
            return 403;
        }

        # 標準的なバックエンド（PHP / Node.js 等）へプロキシ
        proxy_pass http://backend_oauth_cluster;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

—

4. セキュリティチーフからの実務的アドバイス

いいかい、システム設計において「利便性」を理由にバリデーションを緩めることは、セキュリティの文脈では「自ら正面玄関の鍵を壊して回る行為」に等しい。OAuth 2.0を導入する際は、以下の原則をチームの絶対遵守ルールとして定めてほしい。

1. PKCE (Proof Key for Code Exchange) の強制:
ネイティブアプリやSPA（Single Page Application）だけでなく、すべてのOAuthクライアントにおいてPKCEの利用を義務付けろ。仮に認可コードが攻撃者に漏洩したとしても、コードベリファイア（code_verifier）がなければアクセストークンとは交換できないため、これだけでリスクを劇的に低減できる。
2. リダイレクトURIへのワイルドカード禁止:
ドメイン単位での許可や、末尾の部分一致などは絶対に許可するな。パスやクエリも含めた完全一致リストをIDPの管理画面や設定ファイルで厳格に管理すること。
3. 定期的なペネトレーションテスト:
自分たちのシステムが本当に安全かどうかは、実際に攻撃者の視点を持ってファジングやリダイレクトテストを行わなければ分からない。リリース前には必ず、リダイレクトパラメータに対する異常系テスト（境界値分析、ディレクトリトラバーサル、ヌルバイト挿入など）を自動テストスイートに組み込むんだ。

セキュリティは、一人の天才的なエンジニアが守るものではなく、チーム全体の「当たり前の基準」の高さで決まる。今日のこの知見を、すぐさま自社のコードベースに持ち帰り、監査を始めてくれ。健闘を祈る。