OAuth 2.0 リダイレクトURIの「曖昧さ」が招く致命的な帰結
OAuth 2.0において、認可コードやアクセストークンを奪取する攻撃は、今やスクリプトキディの遊び場ではなく、高度な標的型攻撃の定石となっている。特にredirect_uriの検証不備は、認証認可のフローそのものを乗っ取る「鍵のすり替え」を容易にする。
多くの開発者が「ホワイトリストに入れているから大丈夫」と安堵するが、そのホワイトリストの照合ロジックが正規表現による曖昧なマッチングであれば、それはザルで水を汲んでいるに等しい。
なぜ「部分一致」が命取りになるのか
攻撃者は、ターゲットのドメインが許可するリダイレクト先を巧みに捏造する。例えば、https://trusted.example.com が許可されている場合、攻撃者はオープンリダイレクタ脆弱性を持つサブドメインや、パストラバーサルを活用して検証をすり抜ける。
攻撃の構図
1. 攻撃者が用意した不正な認可リクエスト
GET /authorize?client_id=…&redirect_uri=https://trusted.example.com.attacker.com/callback
2. サーバー側が「https://trusted.example.com」で始まる文字列を許可している場合、
検証ロジックを通過してしまう。
このとき、認可サーバーは攻撃者のサーバーへ code を送信する。攻撃者はそのコードを自身のサーバーで受け取り、アクセストークンを正規のトークンエンドポイントから取得する。これが、OAuth 2.0における最も古典的かつ破壊的な権限奪取のメカニズムだ。
厳密な検証を実装するためのアーキテクチャ
ホワイトリスト方式を実装する際、妥協は一切許されない。「完全一致（Exact Matching）」こそが唯一の正解だ。正規表現やサブドメインのワイルドカード指定は、将来的な攻撃の余地を確実に残す。
以下の実装パターンを標準とせよ。
// 安全な検証関数の実装例 (Go)
func validateRedirectURI(requestedURI string, allowedURIs []string) bool {
// 1. URLをパースして正規化（パストラバーサル等の正規化攻撃を防ぐ）
u, err := url.Parse(requestedURI)
if err != nil {
return false
}
// 2. ホスト、スキーム、パスの完全一致を検証
// 末尾のスラッシュやクエリパラメータの順序まで厳密に管理する
for _, allowed := range allowedURIs {
if requestedURI == allowed {
return true
}
}
return false
}
プロトコル仕様の盲点と防御の深化
OAuth 2.0の仕様書（RFC 6749）を読み解くと、リダイレクトURIの検証は認可サーバー側の「必須事項」であることが明記されている。しかし、現実のインシデントでは、開発者が「利便性」を優先し、動的にリダイレクト先を生成する関数を書いてしまうケースが後を絶たない。
さらに、最近の脅威トレンドとして、生成AIを悪用したプロンプトインジェクションにより、内部の認可ロジックを操作しようとする試みも確認されている。ガードレイルとしてのアーキテクチャ設計には、以下の層を追加検討すべきだ。
- 静的解析によるCI/CD統合: 認可エンドポイントへのリクエストパラメータを検証するコードが、正規表現を使用していないか静的解析でブロックする。
- OIDC (OpenID Connect) の採用:
id_tokenの利用とnonceパラメータの強制により、リダイレクト先の不正に関わらずリプレイ攻撃を無効化する。 - トークンバインディング: クライアント証明書や
DPoP (Demonstrating Proof-of-Possession)を導入し、万が一認可コードが漏洩しても、攻撃者の環境ではアクセストークンが使えない状態を作る。
チーフホワイトハッカーからの提言：攻撃者の視点を持て
君たちが書くコードは、単なる「機能」ではない。それはサイバー空間における「防壁」だ。
攻撃者は常に「仕様の隙間」を探している。例えば、ブラウザの挙動を利用した fragment の漏洩や、HTTPのヘッダインジェクションによるリダイレクト先操作など、レイヤ7の脆弱性は複雑に絡み合っている。
リダイレクトURIの検証は、セキュリティの基礎中の基礎だ。しかし、その基礎を極めきれないエンジニアに、耐量子暗号への移行やゼロトラストアーキテクチャの構築を任せることはできない。
結論:
リダイレクトURIのホワイトリストは「完全一致」で固定せよ。動的な変更は一切認めない。それが、我々が守るべきユーザーのデジタルアイデンティティに対する、最低限の敬意である。もし、既存のシステムが柔軟性を求めてワイルドカードを使用しているなら、即刻それを技術的負債として起票し、排除する計画を立てることだ。それが、今の時代を生き抜くエンジニアの責務である。
コメント