OAuth 2.0の「隙間」を突く：Open Redirectと厳密な検証の深淵
OAuth 2.0の仕様書（RFC 6749）を読み込んでいるつもりでも、いざ実装の現場に立つと、多くのエンジニアが「利便性」という名の悪魔に魂を売り、`redirect_uri`の検証を甘く見積もる。
ホワイトハッカーの視点から言えば、Open Redirectは単なる「リダイレクトの誤用」ではない。それは、IDプロバイダ（IdP）が発行した信頼の証（Authorization CodeやAccess Token）を、攻撃者の制御下にあるサーバーへ横流しさせるための「高速道路」だ。
1. なぜ「正規表現」では防げないのか
多くの開発者は、`redirect_uri`を検証する際に正規表現でドメインをマッチングさせようとする。
例：「`^https://.\.example\.com/.$`」のようなパターンだ。
これを見て「おっ、甘いな」と感じる嗅覚が、セキュリティアーキテクトには不可欠だ。この正規表現の盲点は、サブドメインの乗っ取りや、パストラバーサルを悪用したURIの捏造にある。攻撃者は `https://example.com.attacker.com` というドメインを確保するか、あるいは「`@`」記号を使ったURL構造（`https://example.com@attacker.com`）のパース挙動の差異を突き、検証ロジックをすり抜ける。
OAuthの認可フローにおいて、リダイレクト先検証の「正解」は唯一つ。「厳密な文字列完全一致（Strict String Equality）」のみである。
2. コード実装の現場：ホワイトリストの「正解」
柔軟性を持たせたいという要求は開発の現場では常だが、セキュリティにおいて柔軟性は脆弱性の同義語だ。以下に、安全な検証のためのアーキテクチャ例を示す。
// 脆弱な実装を排除し、厳密な検証を行うためのGoによる例
func validateRedirectURI(requestURI string, allowedURIs []string) bool {
// 1. URLをパースして正規化する（Scheme, Host, Pathが揃っているか確認）
parsedReq, err := url.Parse(requestURI)
if err != nil {
return false
}
// 2. ホワイトリストとの完全一致比較
// クエリパラメータを含めた厳密な突き合わせを行う
for _, allowed := range allowedURIs {
if requestURI == allowed {
return true
}
}
// ここでワイルドカードを許可してはならない
return false
}
この実装における肝は、認可サーバー側で「事前に登録されたURIのみ」を許可するデータベースを参照することだ。クライアントが動的に送ってくるURIを盲目的に信用してはならない。
3. トークン漏洩のメカニズム：パケットレベルの観点から
攻撃者がOpen Redirectを悪用する場合、彼らはブラウザの挙動を巧みに操作する。`redirect_uri`を `https://trusted-site.com/callback?data=…` ではなく、攻撃者のサイトに向けさせることで、認可サーバーが発行した `code` パラメータを `Referer` ヘッダやURLログ経由で奪取する。
これがTLS化されているから安全だという時代は終わった。現代の脅威は、クライアント側のスクリプトやブラウザのキャッシュ、さらにはLLM（生成AI）を用いたプロンプト・インジェクションを介して、この「正規の認可レスポンス」を外部へ転送させようとする。
4. 次世代への備え：ガードレイルの設計
今後、私たちは「耐量子暗号（PQC）」への移行や、AIエージェントがOAuthを利用する世界へと向かっている。エージェントが自動的に認可を行う際、そこにOpen Redirectの隙間があれば、AIそのものが「悪意あるリダイレクト先」へ機密情報を運ぶ運び屋になりかねない。
防御のためのアーキテクチャ・チェックリストを提示する。
- Stateパラメータの強制: `state`パラメータがない、あるいは推測可能なリクエストは即座に拒否すること。これはCSRFだけでなく、認可コードを奪う攻撃に対する防波堤となる。
- PKCE (Proof Key for Code Exchange) の必須化: もはやモバイルアプリに限った話ではない。WebアプリケーションでもPKCEを必須とし、認可コードとトークン交換の紐付けを強固にせよ。
- Redirect URIの事前登録: IdP管理画面において、クライアントが事前に登録していないURIへのリダイレクトは、いかなる場合も拒否するハードコーディングを施せ。
結びに代えて
セキュリティは「チェックボックスを埋める作業」ではなく、システムが設計意図通りに動かないケースを徹底的に潰す「知的な格闘技」だ。
`redirect_uri`の検証一つとっても、その裏にはプロトコルの仕様、ネットワークのパケット、そして攻撃者の心理が複雑に絡み合っている。君たちが書くその一行のコードが、次に発生する重大な情報漏洩を止めるかもしれない。
謙虚に仕様と向き合い、傲慢に検証を厳格化せよ。それが、エンジニアが守るべき最後の防壁だ。
コメント