web-dev-qa-db-ja.com

Cookieのベストプラクティスを覚えていますか?

この議論に関する多くの古い質問について読みましたが、ベストプラクティスはusernameuser_idとランダムトークンを使用してCookieを設定することだと思いました。

同じCookieのデータはCookieの作成時にDBに保存され、ユーザーがCookieを持っている場合は、それらが比較されます(Cookieデータ、DBデータ)。

これが本当のベストプラクティスである場合、セキュリティロジックがどこにあるのか理解できません。

Cookieを盗む攻撃者は、元のユーザーと同じCookieを持っています:|

いくつかのステップを忘れましたか? :P

20
itsme

user_idを保存し、ユーザーのパスワードに加えてランダムトークンを発行する必要があります。 Cookie内のトークンを使用し、パスワードが変更されたときにトークンを変更します。このように、ユーザーがパスワードを変更すると、Cookieは無効になります。

これは、Cookieが乗っ取られた場合に重要です。ユーザーがハイジャックを検出すると無効になります。さらに、トークンはパスワードとは無関係であるため、ハイジャッカーはユーザーのアカウントパスワードを取得して変更し、アカウントを「所有」することはできません(既存のパスワードが必要な場合)パスワードを変更する前は、ハイジャッカーは電子メールアカウントを所有していないため、「パスワードを忘れた」などを使用することはできません。

トークンが簡単に推測されないように注意してください(つまり、CRNGからのように、完全にランダムなデータで構成されている必要があります)。

さらに一歩進めたい場合は、送信する前にCookieを暗号化し、受信時に復号化することができます。さらに、ハイジャック犯が使用されている暗号化キーを知らないと思い込まないでください。したがって、復号化時にCookieの内容を検証してください。

とはいえ、独自のセッション管理を行うのではなく、ライブラリの永続的なセッション管理を使用することをお勧めします。

20
ta.speot.is

ハッシュされている場合でも、ユーザーのパスワードをCookieに保存しないでください。

このブログ投稿を見てください:

見積もり:

  1. ユーザーがRememberMeをオンにして正常にログインすると、標準のセッション管理Cookieに加えてログインCookieが発行されます。[2]
  2. ログインCookieには、ユーザーのユーザー名、シリーズID、およびトークンが含まれています。級数とトークンは、適切な大きさのスペースからの推測できない乱数です​​。 3つすべてがデータベーステーブルに一緒に保存されます。
  3. ログインしていないユーザーがサイトにアクセスしてログインCookieを提示すると、ユーザー名、シリーズ、およびトークンがデータベースで検索されます。
  4. トリプレットが存在する場合、ユーザーは認証済みと見なされます。使用されたトークンはデータベースから削除されます。新しいトークンが生成され、ユーザー名と同じシリーズIDでデータベースに保存され、3つすべてを含む新しいログインCookieがユーザーに発行されます。
  5. ユーザー名とシリーズが存在するがトークンが一致しない場合、盗難と見なされます。ユーザーは強い言葉で警告を受け取り、ユーザーが記憶しているセッションはすべて削除されます。
  6. ユーザー名とシリーズが存在しない場合、ログインCookieは無視されます。
52
Danielss89

ユーザー名をCookieに保存することすらしません。 テクニックを解読することはほぼ不可能 で生成されたランダムトークンをデータベース内のユーザーにマップし、neverユーザーのパスワードをCookieにハッシュされていても保存しないと、 ブルートフォース攻撃 に開かれます。はい、誰かがトークンを盗んだ場合、彼はユーザーのアカウントにアクセスできますが、パスワードは危険にさらされず、実際のユーザーがログアウトするとすぐにトークンが無効になります。また、有効なトークンを持っているだけのユーザーにパスワードを変更するなどの機密性の高いタスクを許可しないでください。そのようなタスクでは、パスワードを再度要求する必要があります。

4
nobody

あなたのクッキーが盗まれた場合、誰でもあなたのアカウントにログインすることができます。それは実際にfiresheepが行うことです。セキュリティはランダムトークンにあります。システム全体は、Cookieが盗まれることはないと想定しています。その場合に入る他の唯一の方法は、ランダムトークンを推測することです。あなたがそれを十分に長くするならば、それはほとんど不可能であるはずです。

3
doxin

忘れているように見える「ステップ」は、Cookieの値が適切にハッシュされている場合、攻撃者にとっては少し価値があるということです。

編集:

Cookieの盗難に関連する攻撃からユーザーを保護するためにできることがいくつかあります。

  • ユーザーが最近十分なCookieを持っていない限り、攻撃者がユーザーになりすますことができないように、時間の経過とともにトークンを再生成します。セキュリティが最優先の場合は、リクエストごとにトークンを再生成します(ページの読み込み)。そうでない場合は、パスワードの変更時にトークンを再生成します。
  • ユーザーエージェント のハッシュを保持および検証します。これにより、攻撃者は、ユーザーのCookieとユーザーエージェントの両方を持っていない限り、ユーザーになりすますことができなくなります。

p.s. Cookieは、パスワードハッシュではなく、(ランダムな)トークンを保持する必要があります( 「rememberme」Cookieのハッシュまたはトークン? を参照)。

0
Emanuil Rusev