1

次の認証スタイルを持つ RESTful(ish) API に取り組んでいます。

  • クライアントは「認証」API メソッドを呼び出し、HTTPS POST 経由でユーザー名とパスワードを渡します。このメソッドは、基本的なアカウント情報と、データベース内のユーザー アカウントに保存されている「クライアント トークン」を返します。

  • それ以降のすべての API 呼び出し (HTTPS POST 全体) には、クライアント トークンが必要です。システムがクライアント トークンでリクエスタを見つけられない場合、呼び出しは拒否されます。

私の未解決の質問は次のとおりです。1) だれかがこれに重大なセキュリティ上の問題があると考えていますか? 2) 時間の経過や変更によってクライアント トークンの有効期限が切れる正当な理由はありますか? 現在、すべてのユーザーにランダムに割り当てています。ユーザーがログアウトしたり、パスワードを忘れたりした場合は、新しいパスワードを生成します。

このアプローチに関する皆さんの考えを知りたいです。私は革新を求めているのではなく、このアプローチのリスクを認識させているだけです。

4

1 に答える 1

3

あなたが説明したことは、セッション cookie と機能的に同等であり、アプリケーションに再実装されているだけなので、ほとんどの Web フレームワークで既に対処されている可能性が高い多くの落とし穴があります。

  • トークンに十分なエントロピーがあることを確認してください。トークンが単純な 32 ビット整数である場合、ワイルドな推測で、他の誰かが使用しているトークンを突き止めることができます。
  • これらのトークンをランダムに生成する場合は、暗号的に強力な乱数ソースを使用するようにしてください。そうしないと、前のトークンに基づいて次のトークンが推測できる可能性があります。
  • これらのPOSTリクエストがスクリプトや Web ページに埋め込まれたものから来ている場合、宣言された Cookie としてではなく、明示的なパラメーターとしてトークンを渡し、secureクロスhttponlyサイト スクリプトによるトークンの盗用をより簡単にします。
于 2012-09-18T02:55:05.047 に答える