認可の「穴」を塞げ：OAuth 2.0 リダイレクトURIとワイルドカードの死の淵
認可サーバーの設計において、「利便性」という名の悪魔が囁くことがある。「サブドメインが大量にあるから、https://.example.com/callback としておけば楽だろう？」と。
もし君が今、そんな実装で本番環境を走らせているなら、それは自ら「認可コード窃取への招待状」をインターネットにばら撒いているのと同じだ。今日は、仕様書に書かれた行間を読み解き、なぜ「完全一致（Exact Matching）」以外の選択肢が、現代のセキュリティアーキテクチャにおいて“死”を意味するのかを深掘りする。
—
1. なぜワイルドカードが「脆弱性の温床」となるのか
攻撃者の視点から見れば、リダイレクトURIのワイルドカードは、OAuthフローにおける「唯一の障壁」を無効化する鍵だ。
OAuth 2.0の認可フローにおいて、認可サーバーはredirect_uriの検証を行う。ここでワイルドカードを許容すると、攻撃者は正規のクライアントアプリケーションが持つ「信頼」を、オープンリダイレクタやサブドメイン乗っ取りを通じて悪用できる。
例えば、https://.example.com を許可している場合、攻撃者はhttps://malicious.example.com（もしこのサブドメインが未登録かつ攻撃者が取得可能であれば）をターゲットにする。認可サーバーは「パターンに一致する」と誤判断し、認可コード（code）を攻撃者のサーバーへ送信してしまう。
これが意味するのは、被害者のセッションが攻撃者の手中に落ちるということだ。認証トークンが発行される前に、認可コードを奪うだけでゲームセット。これはクロスサイトスクリプティング（XSS）よりも遥かに効率的で、痕跡を残しにくい。
—
2. 低レイヤから見る「パケットの裏側」
エンジニアはパケットの構造を想像しなければならない。認可サーバーがHTTP 302 Found でクライアントをリダイレクトする際、Location ヘッダーにはユーザーの認可コードがクエリパラメータとして付与される。
もし君の認可サーバーが regex や glob パターンでマッチングを行っているなら、注意が必要だ。URIパースのロジックが甘い場合、以下のような攻撃ベクトルが成立する。
- ホストヘッダーインジェクションの亜種: URIの解析ライブラリが
https://auth.example.com@attacker.comといった構文を許容し、バリデーターが先頭のホスト名だけをチェックしていれば、リダイレクト先は完全に制御される。 - 正規表現の衝突: 複雑な正規表現は、バックトラッキングによるDoSだけでなく、意図しないドメインの包含を招く。
対策：厳密なホワイトリスト実装（Go言語の例）
「柔軟性」を捨て、「堅牢性」をとるのがアーキテクトの仕事だ。以下は、認可サーバー側で行うべき最も安全な照合ロジックの断片である。
// 認可サーバーのバリデーションロジック
func validateRedirectURI(requestURI string, allowedURIs []string) bool {
// 1. 正規化：エンコードされた文字や相対パスの解決を行う
normalizedReq, err := url.Parse(requestURI)
if err != nil {
return false
}
// 2. 完全一致チェック
for _, allowed := range allowedURIs {
// 文字列としての完全一致を強制する
// 許可リストにはワイルドカードを含めないことが大前提
if normalizedReq.String() == allowed {
return true
}
}
return false
}
このコードにおいて、allowedURIs にはあらかじめ登録された完全一致の文字列のみを保持する。DBにはパターンではなく、完全なURLを格納せよ。
—
3. 生成AI時代のガードレイルと「セマンティックな誤解」
最近では、生成AIを用いた認可フローの自動生成や、AIが仲介するAPI呼び出しが増えている。ここで発生するのが「プロンプトインジェクションによるリダイレクト先操作」だ。
AIが動的にリダイレクトURIを構成するようなアプリケーションでは、たとえプログラムコードが正しくても、コンテキストが汚染される。防御層としてのアーキテクチャ設計には、以下の「二重の盾」が必要となる。
1. 認可サーバー側での完全一致（Static Validation）: これは絶対条件。
2. 動的スコープ制限: AIがリクエストを生成する場合でも、クライアントIDに紐付いた「事前に承認済みのリダイレクトURIセット」以外への変更を、APIゲートウェイ層で拒否する。
—
4. 結論：我々が守るべきもの
我々セキュリティエンジニアは、単に「バグを直す」のではない。信頼の連鎖（Chain of Trust）を物理的に切断させないために仕事をしている。
リダイレクトURIのワイルドカードを許容するということは、その連鎖の最も重要なノードを、攻撃者に開放することを意味する。今日の技術的な知見として、以下を肝に銘じてほしい。
- 原則は完全一致: 妥協は「脆弱性」という負債として、必ず将来の自分に返ってくる。
- 認可サーバーは聖域: クライアント側の利便性を理由に、認可サーバーの堅牢性を落とすな。
- 継続的なスキャン: CI/CDパイプラインにおいて、認可サーバーのホワイトリスト設定が正規表現化されていないか、静的解析で常に検知せよ。
複雑なシステムであればあるほど、基本に立ち返る勇気が必要だ。コードを書き換える準備はいいか？ 攻撃者は、君がその設定を「修正しない」ことを期待して待っている。
コメント