web-dev-qa-db-ja.com

セキュリティの向上-Cookie内のセッションIDと暗号化されたCookieの比較

セッションデータを格納するこれらの2つの方法について議論します。

Node-client-sessionsの内部について少し読んだ後、説明する必要のある潜在的な攻撃ベクトルがたくさんあるため、どちらがより安全であるかはわかりません。たとえば、それらは1か所でconstantTimeアルゴリズムを使用することにより、タイミング攻撃を説明します。しかし、さらに多くの潜在的な脆弱性があり、専門家ではないため、ライブラリとしてどれほどうまく機能しているかはわかりません。

一方、データベースにセッションIDを保存するのは無理だと言う人もいます。しかし、少なくともここでは、セッションIDをブラックリストに登録できます。

アドバイスやガイダンスをいただければ幸いです。ありがとうございました。

cookiessession-management
5
Lance Pollard

セキュリティの違いは、主に実装の詳細にあります。基本的には両方のアプローチは同じです。クライアント間で意味のないデータのblobをクライアントに格納して、リクエスト間の状態を維持します。違いは、セッションID Cookieは意味のある情報を表さないため、それ自体は無意味ですが、暗号化されたCookieは、クライアントがデータを復号化する機能を持たないため、無意味です。

暗号化されたCookieは根本的に複雑です。サイズが大きく、複雑なアルゴリズムが必要です。そのアルゴリズムを正しく実装する必要があります。実際のデータが含まれているため、攻撃する価値があり、秘密鍵の管理が必要です。また、分散化された性質のため、取り消すことも困難です。

セッションIDのCookieは単純明快です。意味のないランダムなIDは、他の場所に保存されているデータを参照するだけです。唯一の脆弱性*は推測可能性で、長さを増やし、IDを回転させて期限切れにすることで簡単に防ぐことができます。セッションIDやデータをデータベースに保存することがなぜ悪い考えになるのか、私にはまったくわかりません。データベースが安全である限り、問題はありません。データストアが攻撃を受けやすい場合は、セッションデータが格納されている場所よりも大きな問題があります。

（*すべてのCookieに対する同じ脆弱性である完全なハイジャック、および未定義のセッションIDの受け入れなどの実装固有の欠陥を除く）

そのため、暗号化されたCookieの攻撃面が増えることがステートレスサーバーの利点に値するかどうか、および暗号化の実装を信頼するかどうかを決定する必要があります。高いスケーラビリティについては真剣に検討し、小規模なサービスについては可能な限りシンプルにします。

4
deceze

私が暗号について質問しただけだとすると、私は専門家として私を釘付けにすることはしませんが：

a）適切に暗号化されている場合、Cookieのデータは問題ありません...

  • 結局のところ、エンドユーザーのマシンにデータを保存しています。共有マシンにはあまり適していませんが、アルゴはおそらく十分強力であると主張できます
  • 大量のデータがある場合は、ページが読み込まれるたびにデータを転送するため、アプリケーションの速度が低下する可能性があります。

b）SSL接続を使用している場合は、セッションIDも（適切な長さで）良いはずです。

  • セッションキーの再生成
  • アプリケーションによっては、個人データの表示を最小限に抑えることができます。例えばユーザーの進行状況を追跡するためにセッションを使用するが、ユーザーに（セッションを介して）情報を返さない場合、これはおそらくより安全です。
2
user164613