最近、Cookie を使用してセッション データを保存することを提案する記事をいくつか見つけました。私はこのアイデアが気に入り、正常に動作する CookieStorage クラスを追加してセッション ストレージを拡張しました (ユーザーごとに、データの署名と暗号化に一意のハッシュ キーを使用することに注意してください)。値を暗号化して署名したとしても、Cookie。
個人的には、特にユーザーごとに異なるキーで値を暗号化および署名する場合に、そうしない理由はありません。データが危険にさらされるリスクは、通常のセッションと同じですよね? SSL を使用すると、ハイジャックのリスクがなくなることは言うまでもありません。
セッションデータが大きくない場合、このようなアプローチの利点として私が見ているのは、ストレージがファイル、データベース、メモリベースであるかどうかにかかわらず、セッションデータを開く/読み取る/書き込むためのサーバーでの IO 操作が少ないことです。
この件に関するフィードバックをいただければ幸いです
ありがとう
サーバー側のコンポーネントをまったく使用せずに純粋な Cookie ストレージを使用している場合、ユーザーはデータを制御できます。彼をそれから遠ざける唯一のものは、あなたの暗号化/署名方法です。しかし、それは攻撃することができます。ユーザーのセッションに固有の暗号化/署名キーを使用していない場合 (つまり、サーバー側のセッションを使用していない場合)、静的シークレットにほとんど制限されています。誰かがそれをオフラインで攻撃し、力ずくで攻撃する可能性があります。そうした場合、セッション全体を偽装できます。
サーバー側のセッションに保存された、より安全なワンタイム ランダム シークレットを使用している場合は、既にサーバー側のセッションにデータを保存しています。シンプルに保ち、そこにすべてを保存してみませんか? また、リクエストごとにすべての Cookie をやり取りするために必要な帯域幅も削減できます。
主にサーバー上の I/O 操作を節約するためにこれを行っている場合: memcache ベースのストアのような、より効率的なセッション ストアを使用します。