E Oracle Access Manager (OAM) OAuthセキュリティのベスト・プラクティス

OpenID Connectを介したAPI保護およびフェデレーテッド・ログインにOAuthがますます採用されるようになったため、Internet Engineering Task Force (IETF)はOAuth 2.0 Security Best Practicesを公開しました。この項では、潜在的な脅威を強調し、攻撃者の機能を詳細に説明して、それらのリスクを軽減するための戦略を提供します。

リダイレクト・ベースのフローの保護

次のベスト・プラクティスがサポートされています。

• 苦情処理:
  • クライアント・リダイレクトURIと事前登録済URIの照合
  • CSRFの防止
• ダウングレード攻撃を防ぐための厳密なPKCE設定でのPKCE[2]の使用
• 機密OpenID Connectクライアントは、nonceパラメータを使用できる
• セキュアなクライアント登録
  • クライアントは、認可レスポンスでアクセス・トークンを発行するときに、暗黙的な付与(レスポンス・タイプtoken)またはその他のレスポンス・タイプを使用してはならない
  • クライアントはセキュアなクライアント・タイプのみを使用する必要がある
  • 1つ以上の権限付与タイプを使用するようにクライアントを登録できる
• 発行されたトークンでのissクレームの生成
• 307リダイレクトはサポートされていないため、ユーザー資格証明を含むリクエストが誤って転送されるこことはない

送信者制約の標準化された方法がないため、認可レスポンス中にアクセス・トークンを特定のクライアントにバインドすると、システムは脆弱なままになります。アクセス・トークンが流出した(リークまたはコピー)場合、攻撃者はリソース・エンドポイントでそのトークンを使用できます。このため、アクセス・トークン・インジェクションを防ぐために効果的な手段が実装されていないかぎり、暗黙的付与および同様のレスポンス・タイプの使用はお薦めしません。

トークンのリプレイ防止

OAM OAuthには、リフレッシュ・トークンの再利用を検出し、発行されたすべてのリフレッシュ・トークンを自動的に取り消す機能があります。アクセス・トークンのインジェクションおよびリプレイ攻撃を防ぐには、トークンを特定のクライアントにバインドすることが不可欠です。OAM OAuthは、送信者制約付きアクセスおよびセキュアな権限付与タイプにmTLS (相互TLS)を使用できるようにすることで、この脅威を軽減します。リスクを最小限に抑えるために、発行済トークンの存続期間をできるだけ短く保つことをお薦めします。

アクセス・トークン権限の制限

デプロイメントは、最小権限の原則に従う必要があります。OAM OAuthによって発行されるすべてのアクセス・トークンには、オーディエンスの制限およびクレームが含まれている必要があります。また、クライアントおよびリソース・サーバーは、適切な認可を確保するためにアクセス権を付与する前に、トークンのスコープとオーディエンスの両方を検証する必要があります。

リソース所有者パスワードの資格証明の付与

リソース所有者のパスワード資格証明の付与は、リソース所有者の資格証明をクライアントに公開するため、使用しないでください。OAM OAuthでは、セキュアでない権限付与タイプを使用しないように、セキュアな権限付与タイプのリストを含む明示的なクライアント構成が可能です。OAM OAuthは、下位互換性のためにリソース所有者のパスワード資格証明の付与をサポートしています。

クライアント認証

送信者制約のクライアント認証をお薦めします。OAMでは、非対称暗号化を使用するクライアント認証にmTLS[3]メソッドとprivate_key_jwt[4]メソッドの両方がサポートされます。

その他の推奨事項

OAMサーバーは、クライアントが自身を安全に構成するために使用できるメタデータを公開します。これにより、OAM OAuthサーバーではセキュアな設定のみが公開されるため、クライアントが誤って構成されるのを防ぐことができます。

攻撃と軽減

表E-1 攻撃と軽減

攻撃クラス	攻撃タイプ	対応策	OAM OAuth
不十分なリダイレクトURI検証	認可コード付与に対するリダイレクトURI検証攻撃	リダイレクトURIの厳密なURIマッチングを使用し、ワイルドカードURIマッチングを回避する	厳密なURIマッチングおよびホワイトリストに登録されたURLへのリダイレクトを実装する
	暗黙的付与に対するリダイレクトURI検証攻撃	クライアントは、認可エンドポイントでトークン発行を引き起こすレスポンス・タイプではなく、認可コードを使用する必要がある	PKCEの使用をサポートする
	リダイレクトURIに使用されるセキュアでないHTTPスキーム	クライアントは、リダイレクト・エンドポイントで最初に使用した後に状態値を無効にする必要がある。	下位互換性のためにhttpリダイレクトをサポートするが、それを使用するクライアントは監視する必要がある
リファラ・ヘッダーを介した資格証明漏洩	OAuthクライアントからの漏洩	機密クライアントは、セキュリティ・アーティファクトを含むOAuth構成を安全に格納できる必要がある	診断ログおよび監査ログを生成して、OAuthアクティビティを記録する
	認可サーバーからの漏洩	クライアントはセキュリティ・アーティファクトを定期的に更新する必要がある
		OAM管理者は、アクセス・ログと監査データをモニターして、不正なアクセス・パターンを検出する必要がある
		リダイレクション・エンドポイントで最初に使用した後、クライアントによって状態値が無効にされる必要がある
ブラウザ履歴を介した資格証明漏洩	ブラウザ履歴内の認可コード	クライアントはURI問合せパラメータでアクセス・トークンを渡してはならない。認可コードの付与、またはフォーム・ポスト・レスポンス・モードなどの代替OAuthレスポンス・モードを使用できる。	フォーム・ポスト[5]レスポンスをサポートする
	ブラウザ履歴内のアクセス・トークン
Mix-Up攻撃	侵害されていないサーバーによって発行された資格証明をリリースするようクライアントを欺く侵害された認可サーバー	クライアントは、認可リクエストごとに、認可リクエストを送信した発行者を格納し、この情報をユーザー・エージェントにバインドする必要がある。クライアントは受け取ったトークンの発行者を検証する必要がある。	対話しているクライアントが準拠している必要がある
		クライアントは、対話する発行者ごとに異なるリダイレクトURIを使用する必要がある。クライアントは、発行者の固有のリダイレクトURIと認可レスポンスが受信されたURIを比較して、認可レスポンスが正しい発行者から受信されたことを確認する必要がある。
認可コード・インジェクション	認証コードのリプレイ	クライアントはPKCEとNonceを使用する必要がある。これにより、認可コード・リクエストの検証で、コードがリクエスタに発行され、仲介者がクライアント・レスポンスに別の認可コードを注入していないことを確認できる。	対話しているクライアントが準拠している必要がある
アクセス・トークン・インジェクション	流出した(盗難またはコピー)アクセス・トークンのインジェクション	アクセス・トークンの存続期間はできるだけ小さくする必要がある	対応策がサポートされる
		この攻撃を軽減できるOpenID Connectを使用する
		送信者制約付きアクセス・トークンを使用して、攻撃者がアクセス・トークンを取得することを防ぐ
クロスサイト・リクエスト・フォージェリ	被害者のデバイスからのリクエストを正当なクライアントのリダイレクトURIに注入する	PKCEを使用する	対応策がサポートされる
		または、OAuthの対話のstateまたはnonceパラメータにアンチCSRFトークンを注入する
PKCEダウングレード攻撃		クライアントはPKCEを使用し、状態検証でStrict PKCEフラグを有効にして、CSRF攻撃を防ぐ必要がある。	対応策がサポートされる
リソース・サーバーでのアクセス・トークン漏洩	偽造リソース・サーバーによるアクセス・トークン・フィッシング	送信者制約付きアクセス・トークンを使用する	対応策がサポートされる
	侵害されたリソース・サーバー	使用およびクレーム	リソース・サーバーは準拠している必要がある
		リソース・サーバーを強化し、機密データを保護する必要がある
盗まれたアクセス・トークンの悪用	送信者制約付きアクセス・トークン	送信者制約付きアクセス・トークンを使用する	すべての発行済トークンにaudクレームが含まれる
	オーディエンス限定アクセス・トークン	したがって、リバース・プロキシは、インバウンド・リクエストをサニタイズして、アプリケーション・サーバーのセキュリティに関連するすべてのヘッダー値の信頼性と整合性を確保する必要がある。 リソース・サーバーは、アクセス権を付与する前にスコープとオーディエンスを検証する必要がある	リソース・サーバーでmTLS送信者検証を使用する
オープン・リダイレクト	オープン・リダイレクタとしてのクライアント	リダイレクトは、ターゲットURLが許可されている場合、またはリクエストの発生元と整合性を認証できる場合にのみ実行される	ホワイトリストに登録されたURLにのみリダイレクトできる
	オープン・リダイレクタとしての認可サーバー		厳密なリダイレクトURIマッチングを実装する
307リダイレクト	リダイレクト中の資格証明の潜在的な漏洩	307リダイレクトを無効化	サポート対象外
TLS終了リバース・プロキシ	入力サニタイズの欠如	エンドツーエンドTLSを使用する	デプロイメントは、TLS Everywhereを使用するように構成する必要がある。
リフレッシュ・トークンの保護	リフレッシュ・トークンのリプレイ	送信制約付きリフレッシュ・トークンを使用する リフレッシュ・トークンの再利用の自動検出に続いて発行されたすべてのリフレッシュ・トークンの取消しを有効にする	対応策がサポートされる。
クライアント偽装リソース所有者	リソース所有者に属するリソースにクライアントが誤ってアクセスする	認可サーバーは、クライアントが自身のclient_id、またはリソース・サーバーを混乱させる可能性のあるクレームに影響を与えることを許可すべきではない	クライアントとリソース所有者を区別しない権限付与タイプの使用は推奨されない
		サブ・クレームを含むアクセス・トークンを使用する
クリックジャッキング	フレーム制限の発生元がない	OWASPアンチクリックジャッキング・メカニズムを使用する	対応策がサポートされる
ブラウザ内通信フローに対する攻撃	受信者オリジンの制限が不十分	HTTP POST over HTTPリダイレクトを使用する	深層防御アプローチが必要
	不十分なURI検証	ワイルドカードURIの使用を避ける	悪意のあるアクセスのデプロイメントをモニターする必要がある。
	不十分な送信者オリジン検証の後のインジェクション	認可レスポンスを保護するメカニズムを適用する