web-dev-qa-db-ja.com

OAuth 2つの状態トークンとCSRFの保護

REST APIのセットを作成しようとしています。これは、OAuthによって生成された添付IDトークンを使用して認証されます）プロバイダー。

OAuthの間にリダイレクトURLで渡された状態トークンを使用する方法を理解しようとしています承認フロー "。

次のシナリオで、状態トークンはどのようにして攻撃を防止しますか？

前提：バックエンドOAuthクライアント（REST APIリクエストを処理する）は、次のセッションマップを持っています- ユーザー<->状態トークン。

シナリオ：

  1. 悪意のあるユーザーがサービスで認証を試みます。
  2. 私たちのサービスは、状態トークンを使用してOAuthプロバイダーへの認証URLを生成します。状態トークンは、サーバー上の悪意のあるユーザーに添付されています。
  3. 悪意のあるユーザーは認証URLで自分自身を認証し、サーバーに到達する前にリダイレクトURLリクエストをトラップします。
  4. ここで、彼がサービスの有効なユーザーにトラップされたリダイレクトURLに強制的に移動させたと想定します。
  5. OAuthクライアント（サーバー）がリダイレクトURLを受信すると、状態トークンが検証されます。これは次の理由によります。
    • uRL内のOAuthコードは、OAuthプロバイダーによって悪意のあるユーザーのIDと一致するIDトークン。
    • OAuthクライアント（サーバー）は、URL内の状態トークンを、IDトークンが保持するIDに関連付けられた状態トークンと比較します。
  6. これで、有効なユーザーが悪意のあるユーザーのアカウントを操作し、機密情報を悪意のあるユーザーに明らかにする可能性があります。

そのような攻撃からどのように保護しますか？または、状態トークンの検証を実装する方法に何か不足していますか？.

csrfattack-preventionoauth
2
Vikram Praveen Kumar

そのような攻撃からどのように保護しますか？

これはまさに攻撃のシナリオであり、状態パラメーターは保護のために使用されます。

または、状態トークン検証を実装する方法に何か不足していますか？.

はい、キーは詳細にあります。から RFC6749 ：

The client MUST implement CSRF protection for its redirection URI.
This is typically accomplished by requiring any request sent to the
redirection URI endpoint to include **a value that binds the request to
the user-agent's authenticated state** (e.g., a hash of the session
cookie used to authenticate the user-agent).  The client SHOULD
**utilize the "state" request parameter to deliver this value** to the
authorization server when making an authorization request.

Once authorization has been obtained from the end-user, the
authorization server redirects the end-user's user-agent back to the
client with the required binding value contained in the "state"
parameter.  **The binding value enables the client to verify the
validity of the request by matching the binding value to the
user-agent's authenticated state**.  The binding value used for CSRF
protection MUST contain a non-guessable value (as described in
Section 10.10), and the user-agent's authenticated state (e.g.,
session cookie, HTML5 local storage) MUST be kept in a location
accessible only to the client and the user-agent (i.e., protected by
same-Origin policy).

したがって、重要なのは、状態の値を何らかの方法で開始側ユーザーのセッションにバインドする必要があることです。 RFCは、これを行う方法に関する提案を提供します。

OAuthクライアント（サーバー）がリダイレクトURLを受信すると、状態トークンが検証されます。これは、[...]

これが状態パラメータの出番です。状態パラメータを検証する前にアクセスコードを交換しないです。

このフローを開始したユーザーに属する値であることを確認して、状態を検証します。上記の状況では、状態は攻撃者に属し、現在の要求者が被害者であるため、これは失敗するはずです。

1
Daniel Szpisjak