0

私の Web アプリでは、次の方法で認証を処理します。

  1. ユーザーは自分のメールアドレスとパスワードを入力します

  2. データベースでユーザーを検索し、bcrypt で暗号化されたパスワードと一致しますか?

  3. その場合、新しいセッション レコードがデータベースに保存されます。これは、ユーザー ID と 128 ビットのランダム キーです。また、このキーは「安全な」「http のみ」の Cookie としてクライアントに保存されます。

  4. ユーザーが Web アプリにリクエストを行うたびに、キーはデータベース内のセッションを検索するための参照になります。セッションがある場合 -> 認証済み。

  5. セッションは一定時間 (例: 3 時間) 後に削除されます。

注: すべてのリクエストは SSL 暗号化されています。

この認証手順に欠陥はありますか? これを使用する場合、どのような危険が考えられますか?

ありがとう！

エリアス

4

1 に答える 1

1

ここで 2 つの DoS 攻撃のシナリオを見ることができます。

  1. ボットは、サーバーでランダム セッション ID を使用してランダム リクエストを発行できます。その結果、非常に多くのセッション ルックアップが発生する可能性があります。DB に対してチェックされる前に、アルゴリズムを使用してセッション ID が有効なセッション ID であることを検証できる場合、理想的にはセッション管理が圧倒される可能性があります。のほうがいい。
  2. ログイン画面は、さまざまな uid/pwd の組み合わせを持つボットによってヒットされる可能性があり、その結果、DB で複数の user/pwd 検索が行われます。LRU の uid/pwd キャッシュをメモリに配置すると、この問題に対処できます。また、同じ IP からの複数のログイン リクエストのキャプチャにも対処できます。

あなたが触れなかった1つのポイントは、いつセッションを期限切れにするかということです-ユーザーがログアウトしない場合、いつテーブルからセッションIDを消去しますか? その間、セッション ID が Cookie からハイジャックされた場合はどうなりますか?

于 2012-04-18T08:23:57.753 に答える