4

ユーザーがサイトにログインすると、2 つの Cookie が作成されます。1 つはセッション ID (バックエンドのユーザー ID に関連する) を持ち、1 つは 3 か月間保持される記憶 Cookie です。

リメンバーミー Cookie は次のように構成されます。

userid:timeout:hash

userid:timeoutハッシュは、改ざんを防ぐための HMAC SHA256 ハッシュです。

セッション ID が存在しない場合 (ユーザーがブラウザーを閉じて再度開いたために Cookie がなくなった場合、またはセッション ID が memcached に存在しない場合)、記憶 Cookie を確認し、新しいセッション Cookie を再生成します。タイムアウトではなく、ハッシュは正しいです。

ただし、セッション ID はバックエンドのユーザー ID を指しているだけなので、セッション cookie を持つ意味がまったくわかりません。代わりに、remember me cookie を使用して現在のユーザーを取得できます。

そのため、私はセッション Cookie を完全に廃棄することを考えており、これについていくつかの意見を聞きたいと思っています。このアプローチは比較的安全に聞こえますか? もっと良くすることはできますか？

前もって感謝します！

4

1 に答える 1

1

はい、それは確かにほとんどの場合に十分に安全ですが、それを避けることができるのになぜユーザー固有のデータをCookieに含めるのですか？また、これには小さな欠点があります。

ユーザーが別のユーザーからCookieを盗むことができた場合は、Cookieの生成方法全体を変更する必要があります。そうしないと、そのユーザーは常にアクセスできるため、全員のCookieがリセットされます。盗まれたのはあなたのクッキーだと想像してみてください...

これが私の解決策です。ユーザーテーブルに「userhash」という別の行を作成します。ユーザーがログインすると、入力を一切受け取らずにランダムなハッシュを生成し、それをテーブルとCookieの両方に保存します。userhash:timeoutその後、Cookieに保存するだけで済みます。データベースに対してそれをチェックして、データベースが存在するかどうかを確認します。存在する場合は、それがユーザーです。ユーザーがログアウトすると、データベース内のCookieと行が削除されます。明らかな理由から、比較する前にCookieが存在することを確認する必要があります（多くの空のものがあります）。

注：この方法では、一度に1つの登録済みCookieのみが許可されるため、ラップトップとデスクトップは許可されません。これは、実際のユーザーがログインしない限り盗むのが難しくなるので良いことですが、1台のコンピューターしか許可されないので悪いことです。しかし、あなたはこの方法をどのように使用できるかという考えと方法を理解していますが、複数のコンピューターをログインさせています...Facebookのようです。

PDさん、アプリが実際にどれだけ安全でなければならないかと言っていただければ幸いです...

PD2、まだ考えていない場合は、他にも深刻なセキュリティ上の懸念があります（SSLなど）。

于 2013-03-05T15:55:24.087 に答える