4

OAuth 2.0 Threat Model and Security Considerationsドラフトから:

4.4.1.13. 脅威: コード置換 (OAuth ログイン)

攻撃者は、被害者の ID を使用してアプリケーションまたは Web サイトへのログインを試みる可能性があります。OAuth で保護されたサービス API によって提供される ID データに依存してユーザーをログインさせるアプリケーションは、この脅威に対して脆弱です。このパターンは、いわゆる「ソーシャル ログイン」シナリオで見られます。

前提条件として、リソース サーバーは、ユーザー ID を取得したと解釈されるユーザーに関する個人情報を取得するための API を提供します。この意味で、クライアントはリソース サーバー API を「アイデンティティ」API として扱っています。クライアントは、OAuth を使用して ID API のアクセス トークンを取得します。次に、ID API に ID を照会し、それを使用して内部ユーザー アカウント データ (ログイン) を検索します。クライアントは、ユーザーに関する情報を取得できたので、ユーザーが認証されたと見なします。

クライアントが付与タイプ「コード」を使用する場合、攻撃者は、標的のクライアント アプリケーションで使用されているのと同じ ID プロバイダーから、それぞれの被害者の有効な認証コードを収集する必要があります。攻撃者は、ターゲット アプリケーションと同じ ID プロバイダーを使用して、被害者をだまして悪意のあるアプリ (ID プロバイダーにとっては正当に見える可能性があります) にログインさせます。これにより、ID プロバイダーの承認サーバーがそれぞれの ID API の承認コードを発行します。次に、悪意のあるアプリはこのコードを攻撃者に送信し、攻撃者はターゲット アプリケーション内でログイン プロセスをトリガーします。攻撃者は認証応答を操作し、被害者のコードを (ID にバインドされた) 自分のコードに置き換えます。このコードは、クライアントによってアクセス トークンと交換されます。これは、リソース サーバーに関してオーディエンスが正しいため、ID API によって受け入れられます。しかし、ID API によって返される ID は、(被害者のコードに基づいて発行された) アクセス トークンの ID によって決定されるため、攻撃者は被害者の ID でターゲット アプリケーションにログインします。

影響: 攻撃者は、アプリケーションおよびアプリケーション内のユーザー固有のデータにアクセスできます。

対策:

  • すべてのクライアントは、アクセス トークンの承認コードを交換するすべての要求でクライアント ID を示す必要があります。認可サーバーは、特定の認可コードが特定のクライアントに発行されているかどうかを検証する必要があります。可能であれば、クライアントは事前に認証されます。

  • クライアントは、OpenID (cf. [openid]) や SAML (cf. [OASIS.sstc-saml-bindings-1.1]) などの適切なプロトコルを使用して、ユーザー ログインを実装する必要があります。どちらも、クライアントでの対象者の制限をサポートしています。

「攻撃者は、ターゲットのクライアント アプリケーションで使用されているのと同じ ID プロバイダーから、それぞれの被害者の有効な認証コードを収集する必要があります」。「それぞれの犠牲者」とは何ですか?「ID プロバイダー」は、この使用とその後の使用で何を意味しますか?

攻撃の説明全体が不明瞭です。「OAuth 2.0 を使用してユーザー ログインを実装するべきではない」と理解するようになりましたが、それは Facebook などの主要なプラットフォームが脆弱であるということではないでしょうか。そして、正確には何に対して脆弱ですか？

おそらく、この段落で使用されている用語のいくつかを明確にする必要があるだけです.

4

1 に答える 1

7

答えは自分で見つけました。このセクションの言葉遣いは少しわかりにくいですが、攻撃は非常に単純です。「ID プロバイダー」は、ユーザーの身元を確認するために使用されるリソース サーバーの名前です。

基本的には、クライアントアプリに対して発行された認証コードを利用して、別のアプリでアクセストークンを取得するケースです。より明確な方法で手順の概要を説明しようとします。

  1. 攻撃者が悪意のあるクライアントを登録します (例: Facebook に登録されたアプリ)。
  2. 被害者のユーザーは、OAuth 2.0 の authentication_code フローをトリガーする「サードパーティでログイン」ボタン (「Facebook にログイン」など) を使用して悪意のあるクライアントにログインするようにだまされます。
  3. 悪意のあるクライアントは、authorization_code を取得します。
  4. 攻撃者は、取得したばかりの authentication_code を別のアプリで使用し、被害者ユーザーとしてそのアプリへのアクセスを取得します。

ステップ 4 は、authorization_codes が特定のクライアントにバインドされていない場合にのみ可能です。クライアントに発行された認証コードは、同じクライアントのみがアクセス トークンを取得するために使用できます。

もちろん、Facebook は脆弱ではありません。認証サーバーからの基本的なチェックだけで無効にできるからです。

于 2012-10-18T17:04:24.463 に答える