認可コードの「通り道」を塞げ：OAuth 2.0 リダイレクトURI検証の深淵
OAuth 2.0は、現代のID基盤の要石だが、その仕様の柔軟さが裏目に出るケースが後を絶たない。特に、認可コードフローにおけるリダイレクトURIの検証不備は、単なる「実装ミス」の範疇を超え、攻撃者にとっての「正当な特権昇格のトンネル」になり得る。
今日は、教科書的な「URLをチェックしましょう」といった退屈な話はしない。なぜホワイトハッカーがこの一点を執拗に攻めるのか、その技術的な急所を掘り下げよう。
—
1. なぜ「ワイルドカード」が牙を剥くのか
多くの開発者は、柔軟性を求めて `https://app.example.com/` のようなリダイレクトURIの許可設定を行いがちだ。しかし、これが攻撃のトリガーとなる。
認可コード（Authorization Code）は、攻撃者の支配下にある悪意あるドメインへ漏洩させるのが定石だ。攻撃者がターゲットのブラウザを操作し、偽のリダイレクトURIを認可リクエストに含めて送出させる「認可コード窃取攻撃」において、サーバー側が「前方一致」や「正規表現による緩い比較」を行っていると、攻撃者は自身の管理するサブドメインや、オープンリダイレクト脆弱性を持つ別ページを検証の網目に潜り込ませる。
攻撃ロジックの核心
1. 認可リクエストの改ざん: 攻撃者は正当なクライアントの `client_id` を使い、`redirect_uri` を自分たちが制御できるエンドポイント（例: `https://app.example.com.attacker.com/callback`）へ変更してユーザーを誘導する。
2. コードの横取り: 認可サーバーがこれを「許可リスト内」と誤認すれば、認可コードを攻撃者のサーバーへ送信する。
3. セッション乗っ取り: 攻撃者は入手したコードを自身のクライアント秘密鍵（あるいはPKCEのコードベリファイア回避）と組み合わせ、アクセストークンを取得する。
これを防ぐ唯一の道は、「完全一致（Exact Match）」の原則を死守することだ。
—
2. 厳密な検証のためのアーキテクチャ設計
実装レベルでやるべきことは明白だが、現場では「バリデーションロジックの共通化」で詰むことが多い。以下の設計指針を推奨する。
サーバーサイドの検証実装例 (Go言語での例)
// 許可されたリダイレクトURIのリスト
var allowedRedirectURIs = map[string]bool{
“https://api.myapp.com/callback”: true,
“https://web.myapp.com/callback”: true,
}
// 厳密な検証ロジック
func validateRedirectURI(requestedURI string) error {
// 1. URLのパース
u, err := url.Parse(requestedURI)
if err != nil || u.Scheme != “https” {
return errors.New(“Invalid scheme”)
}
// 2. 完全一致チェック (前方一致や正規表現は一切排除)
if !allowedRedirectURIs[requestedURI] {
// ログには詳細を出すが、ユーザーには一般的なエラーを返す
log.Printf(“Security Alert: Unregistered redirect URI attempted: %s”, requestedURI)
return errors.New(“Unauthorized redirect URI”)
}
return nil
}
この実装における肝は、「URI構造の正規化」を検証の前に行うことだ。パスのトラバーサル（`..`）や、ポート番号の省略による不整合を突く攻撃は、パケットレベルではなく、アプリケーションのURIパーサーの挙動の差を利用してくる。
—
3. PKCEの強制化：最後の防衛層
リダイレクトURIの検証がどれほど厳密でも、実装の隙間はゼロにはならない。そこで、現在では PKCE (Proof Key for Code Exchange) の強制化が必須だ。
PKCEは、認可コードを窃取したとしても、それと対になる `code_verifier` がなければトークン交換を完了させない仕組みだ。これは、OpenID Connectの仕様上、もはや「オプション」ではなく「防衛ライン」である。
- 攻撃者がコードを盗む: 成功。
- 攻撃者がアクセストークンを請求する: `code_verifier` がないため、認可サーバーは拒絶する。
もし、貴方のアーキテクチャで `code_challenge_method` が `plain` で許可されているなら、今すぐ `S256` に制限すべきだ。`plain` は中間者攻撃に対して無防備であり、最新のセキュリティガイドラインでは非推奨とされている。
—
4. チーフホワイトハッカーからの提言：監査とガードレイル
最後に、システムを構築するテックリードたちへ。コードを書くこと以上に重要なのが「監査」だ。
1. 認可リクエストのロギング: 失敗したリダイレクトURIの試行回数を異常検知（SIEM）に組み込め。特に、許可リストにないURIへのアクセスは、攻撃の予兆（Reconnaissance）である可能性が高い。
2. 生成AIによるコードレビューの限界: GitHub Copilot等のAIはコードの「機能」は書くが、OAuthの微妙な仕様差異による脆弱性を見抜くには、専用の静的解析ツール（SAST）と、OAuthの仕様を理解したシニアエンジニアによるレビューが依然として不可欠だ。
3. 将来への備え: 耐量子暗号（PQC）への移行期において、IDトークンの署名アルゴリズム（JWS/JWE）の更新計画を立てておけ。現状のRSA/ECDSAが崩壊する際、認可コード自体の保護層が唯一の砦になる。
セキュリティとは、完璧な製品を作ることではない。「攻撃者がコストを払い続け、最終的に諦めるような堅牢な構造」を維持し続けることだ。
OAuthのリダイレクトURI検証は、そのための最も基本的な、しかし最も軽視してはならない防御術である。貴方のシステムのコードに、妥協の余地はないはずだ。
コメント