2

これは、JavaScriptの詳細に関する特定の質問ではありませんが、作成したモデルに明らかな穴がないことの検証を探しています。私は自分の認証ルーチンをロールすることにしました（バックエンドでハッシュするためにbcryptを使用することを除いて）これは次のように機能します：

  1. ユーザー（ブラウザーまたはphonegapで作成されたネイティブアプリ）がサインアップ> jQueryajaxを使用して投稿されたJsonオブジェクトをバックエンドに投稿します。バックエンドはbcryptを使用してパスワードを処理し、パスワードのユーザープロファイルデータを保存します
  2. バックエンドは、クライアントIPアドレスで返すトークンを生成し、保存します（/ dev / urandomなどのランダムハッシュ）
  3. jQueryプラグインはトークンをローカルCookieに保存します
  4. 何らかのリクエスト（投稿、コメントなど）が行われると、Cookieからトークンを取得し、それをjsonに追加して、ajaxで再度投稿します。
  5. バックエンドは、トークンが存在し、有効期限が切れていないことを確認し（7日間有効）、IPアドレスが同じであることを確認し、okの場合はリクエストのjsonデータを検証してリクエストを処理します
  6. トークンの有効期限が切れると、ログイン画面が表示され、手順2のように、資格情報がajaxとして投稿され、新しいトークンが作成されます。

すべてがajaxリクエストのSSLを通過し、パスワードはどこにも保存されません。しきい値を超えた場合にソースIPを一時的にブロックするブルートフォーストークンスパムをチェックするメカニズムもあります。これはセキュリティの高いアプリではありませんが、ユーザーデータを尊重し、「十分」に安全であることを確認する必要があります。

具体的ではありませんが、質問が適切であり、議論のきっかけとなる場合は、他の誰かの参照として機能することを願っています。この特定のアプローチに関するベストプラクティスのチュートリアルは見つかりませんでした。

更新：認証メカニズムは、重要ではないWebアプリケーションに対して「十分に安全」であると思われるため、受け取ったフィードバックに従って更新されました。

4

1 に答える 1

2

あなたのアプリケーションは高度なセキュリティのアプリではなく、基本的なセキュリティ制御が必要であるとあなたが言ったことを考慮して、私は高レベルの観点から考えられるすべてをカバーしようとしました.

認証フローとそれが使用しているメカニズムは、私には問題ないようです。ここで気になる点は、セッション管理自体です。MD5 を使用してセッション トークンを生成することは問題ありません (正しい方法でシードされた正しい疑似乱数関数を使用しているかどうかによって異なります)。

ここに欠けているものがいくつかあります - それらは省略されているか、存在しない可能性があるため、それらすべてについて言及します。まず第一に、ユーザーと受け取った Cookie が確実に一致するかどうかについて言及していません。1 人のユーザーが 2 番目のユーザーのセッションを盗むことができないように、これら 2 つが一致していることを確認する必要があります。

ここで欠けている 2 番目のことは、Cookie が元のユーザーから盗まれていないことの検証です。たとえば、ユーザーからセッション Cookie を盗み、別の場所から自分のコンピューターで再生した場合でも、現在のセッション処理メカニズムを使用してログインできます。

リクエストがどのコンピューターから来ているかを一意に識別する方法が必要です。それを行う 1 つの方法 (および CodeIgniter と呼ばれる PHP フレームワークがそれを行う方法) は、IP アドレスと、リクエストが送信されたユーザー エージェントを確認することです。から来る。後者はなりすましが簡単ですが、前者ははるかに困難です。これにより、アプリケーションが公共のマシン上のインターネット カフェで使用され、ユーザーがログオフしていない場合を除き、セッションは攻撃に対してより回復力があります。

ここで、最後のポイントに進みます。ここで言及されているログアウト メカニズムと、ログアウトがどのように実行されるかはわかりません。基本的な仮定は、ユーザーがログアウトするとすぐにセッション Cookie を無効にし、そのセッション Cookie を再度受け入れないことです。これをまだ行っていない場合は、セッションのセキュリティを確保するために別の方法で行うことができます。

于 2012-07-21T08:42:26.293 に答える