13

OAuth2.0v20用のPHPライブラリを使用しています

ドラフト20には、CSRFを防ぐための状態の使用についての言及があります

これまでのところ、このPHPライブラリを実装する私自身のWebアプリでは、次のことが可能です。

  1. 認証コード要求を使用した3本足の認証
  2. Resource OwnerCredentialsGrantを使用した2本足の認証
  3. アクセストークンを更新するリクエスト

上記の3つの状況すべてに状態を使用する必要がありますか？

もしそうなら、「状態」の良い例は何ですか？

何が良い「状態」になるのでしょうか？

理想的な長さはありますか？最小の長さはありますか？最大長はありますか？

理想的なメイクはありますか？大文字を含む英数字？

4

3 に答える 3

38

状態パラメータがこのような攻撃をどのように軽減するかを理解するために、CSRFエクスプロイトの例をステップスルーすると役立つ場合があります。この例では、マロリーが攻撃者であり、アリスが犠牲者です。

攻撃

  1. マロリーはクライアントのWebサイトにアクセスし、そのクライアントがOAuthを使用してサービスプロバイダーにアクセスすることを承認するプロセスを開始します

  2. クライアントは、サービスプロバイダーに、マロリーに代わってアクセスを要求する許可を求めます。これは許可されます。

  3. マロリーはサービスプロバイダーのWebサイトにリダイレクトされ、アクセスを許可するために通常はユーザー名/パスワードを入力します。

  4. 代わりに、マロリーはこのリクエストをトラップ/防止し、そのURLを保存します

  5. さて、マロリーはどういうわけかアリスにそのURLを訪問させます。アリスが自分のアカウントでサービスプロバイダーにログインしている場合、彼女の資格情報は認証コードを発行するために使用されます

  6. 認証コードがアクセストークンと交換されます

  7. これで、クライアントのマロリーのアカウントは、サービスプロバイダーのアリスのアカウントにアクセスすることが許可されます。

stateでは、パラメータを使用してこれを防ぐにはどうすればよいでしょうか。

防止

  1. クライアントは、元のユーザーのアカウントに何らかの形で基づいた値を作成する必要があります（たとえば、ユーザーのセッションキーのハッシュ）。それが一意であり、元のユーザーに関するいくつかのプライベートで推測できない情報を使用して生成されている限り、それが何であるかは問題ではありません。

  2. この値は、上記の手順3からのリダイレクトでサービスプロバイダーに渡されます

  3. これで、マロリーがアリスに保存されたURLにアクセスさせると（上記のステップ5）、そのURLにはstateマロリーのセッション情報で生成されたパラメーターが含まれます。

  4. 認証コードが発行され、マロリーのパラメータとともにアリスのセッションでクライアントに返送されますstate

  5. クライアントは、アリスのstateセッション情報に基づいて新しい値を生成し、それを承認要求からサービスプロバイダーに返送された値と比較します。この値はマロリーのセッション情報に基づいて生成されたため、リクエストのパラメーターと一致しません。そのため、この値は拒否されます。statestatestate

攻撃者は特定のユーザーの状態値を生成できないようにする必要があるため、ユーザーをだまして認証URLにアクセスさせても効果はありません。

于 2014-05-13T19:58:10.787 に答える
16

＃1の場合-認証コードフローを使用した3本足の認証。

アプリケーションが認証コードをアクセストークンと交換する場合、認証コードが提供される結果となったOAuthフローが実際に正当なユーザーによって開始されたことを確認する必要があります。そのため、クライアントアプリケーションがユーザーをプロバイダーにリダイレクトしてOAuthフローを開始する前に、クライアントアプリケーションはランダムな状態値を作成し、通常はサーバー側のセッションに保存します。次に、ユーザーがOAuthフローを完了するときに、状態値がユーザーのサーバー側セッションに保存されている値と一致することを確認します。これは、ユーザーがOAuthフローを開始したことを示します。

状態値は通常、疑似ランダムの推測できない値である必要があります。単純な値は、PHPのrand（）関数を使用してintとして生成できますが、より複雑になって保証を強化することもできます。

この状態は、アカウントの認証コードを含むリンクを電子メールで送信したり、クリックしたり、アプリケーションが知らないうちにすべてのデータをアカウントにプッシュしたりすることを防ぐために存在します。

いくつかの追加情報は、OAuth 2.0脅威モデルドキュメントにあります： https ：//datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-threatmodel-00

特に、CSRF保護に関するセクションを参照してください： https ：//datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-26#section-10.12

于 2012-06-18T04:38:06.583 に答える
-3

「状態」は単なるランダムな文字列であるため、次のようなものを作成するとうまくいくはずです。

$state = md5(uniqid(rand(), TRUE));

後で確認できるように、セッションに保存することを忘れないでください。

于 2012-10-26T17:39:06.173 に答える