OAuthの脆弱性と攻撃パターン

OAuth認可サーバーは、redirect_uriパラメーターを厳密に検証する必要があります。サーバーが前方一致やワイルドカード一致を許可すると（たとえば「https://app.example.com」で始まる任意のURLを受け入れる場合）、攻撃者は「https://app.example.com.attacker.com/steal」や、正規のドメイン上にあるオープンリダイレクトへリダイレクトする認可リクエストを作成し、認可コードを盗むことができます。

CSRF対策がない場合、攻撃者はOAuthフローを開始し、被害者のブラウザーをだまして認可を完了させることができます。被害者は意図せず攻撃者のクライアントを認可してしまいます。「state」パラメーター（RFC 6749）はこれを防ぎます。クライアントがランダムなstateを生成してリクエストに含め、コールバックで一致することを検証します。一致しなければフローを中止します。

モバイルプラットフォームでは、悪意のあるアプリが正規のOAuthクライアントと同じカスタムURIスキームを登録し、ユーザー認証後にリダイレクトされた認可コードをインターセプトする可能性があります。PKCE（RFC 7636）が完全な防御策となります。インターセプトされたコードは、フローの開始時に正規のアプリだけが生成したコード検証子がなければ利用できません。

IDトークンやアクセストークンがURLフラグメントまたはクエリパラメーターに含まれていると、そのページから以降のページへ移動する際にURLがRefererヘッダーに含まれ、サードパーティの分析スクリプトやCDNプロバイダーにトークンが漏えいする可能性があります。トークンがURLに現れないように、必ず認可コードフローとバックチャネルでのトークン配信を使用してください。

クライアントが複数のOAuthプロバイダーに対応している場合、ミックスアップ攻撃によって、Provider Aから取得した認可コードをProvider Bのトークンエンドポイントに送信させられる可能性があります。クライアントは、IDトークンの「iss」クレームを検証し、stateパラメーターまたはJARM（JWT-Secured Authorization Response Mode）を使って、コールバックをフローを開始した特定のプロバイダーに結び付ける必要があります。

サーバーサイドリクエストフォージェリ（SSRF）攻撃は、redirect_uriに対してサーバー側のHTTPリクエストを行うOAuth実装を標的にします。認可サーバーが検証のためにredirect_uriを取得する場合、攻撃者は内部IPアドレス（たとえば http://169.254.169.254/latest/meta-data/）を指定し、クラウドインスタンスのメタデータや内部サービスにアクセスできます。厳密な許可リスト方式でredirect_uriを検証すれば、この攻撃を防止できます。

多くのアプリケーションは、OIDC IDトークンのemailクレームを使ってプロバイダー間のアカウントを関連付けています。攻撃者が、別のプロバイダーにある被害者のアカウントと一致するメールアドレスを管理している場合、そのメールアドレスを使って別のプロバイダーに登録し、被害者のアカウントにアクセスできる可能性があります。対策は、メールアドレスだけでなく、（iss、sub）の組み合わせだけでアカウントを関連付けることです。

JWTアルゴリズム混同攻撃は、「alg」ヘッダーを信頼して検証アルゴリズムを選択する実装の弱点を悪用します。攻撃では、「alg」を「RS256」から「HS256」に変更し、サーバーの公開鍵をHMACの秘密鍵としてトークンに署名します（公開鍵は公開されているためです）。対策として、検証コードで想定するアルゴリズムを必ず明示し、トークンヘッダーのalgクレームを決して信頼しないでください。

攻撃者は、正規アプリに見える名前とロゴで悪意のあるOAuthクライアントを登録し、標的にフィッシングリンクを送ります。被害者には、悪意のあるアプリケーションに対する本物のOAuth同意画面（GoogleやMicrosoftなどがホストするもの）が表示され、アクセスを許可してしまいます。対策として、client_idが想定するアプリケーションに対応していることを確認してください。GoogleとMicrosoftは、正規アプリ向けにクライアント検証プログラムを提供しています。

スコープエスカレーションは、クライアントがユーザーの認可した範囲を超える、より広い権限を持つトークンを取得したときに発生します。トークンエンドポイントでのスコープ検証を省略すること、異なるリクエストのスコープを統合してトークンをキャッシュすること、発行したトークンのスコープが認可されたスコープを超えていないことを検証しないことなどの実装上の欠陥は、OAuthを介した権限昇格につながる可能性があります。

OAuth実装を防御するには、redirect_uriを完全一致で検証し、すべてのパブリッククライアントにPKCEを要求し、CSRF対策としてstateパラメーターを検証し、IDトークンをメールアドレスではなく（iss、sub）で結び付け、想定するJWTアルゴリズムを明示し、最小限のスコープを要求し、短期間で期限切れになるアクセストークンとリフレッシュトークンローテーションを使用し、ブランド偽装のリスクがないか同意画面の表示を監査します。

OAuth認可サーバーが、「https://app.example.com」で始まるredirect_uriをすべて受け入れるとします。これによって、どのような攻撃が可能になりますか？

主なOAuth攻撃には、redirect_uriの検証が緩いことによるオープンリダイレクト（完全一致を使用）、stateパラメーターの欠如によるCSRF、モバイルでのコードインターセプト（PKCEで緩和）、URL内のトークン漏えい、複数プロバイダー構成でのミックスアップ（issを検証）、サーバーが取得したredirect_uriを介したSSRF、メールクレームの衝突（iss+subを使用）、JWTアルゴリズム混同（想定するalgを固定）、偽の同意画面によるフィッシングがあります。