Web 2.0アプリケーションでは、多くのユーザーは通常、ログインしたままにしておきたい（「remember me」フラグ）一方で、Cookieを使用して非常にプライベートなデータにアクセスできます。コンピューターから直接またはスニッフィングを介してCookieを盗む誰かがCookieを使用してユーザーのデータにアクセスできないようにする方法はありますか？常にHTTPSはオプションではありません。
ありがとう、ベルント
[編集]IPアドレスをCookieに接続することもオプションではありません。
KISS -- 選択したサーバー側スクリプト言語によって既に自動的に作成されている ID を使用するようにセッションを使用するだけです。それは推測するのに十分難しいです。次に、盗まれた場合は、訪問者の IP アドレスとユーザー エージェントをセッションに保存し (出力しないようにします) 、既に保存されているIP アドレスとユーザー エージェントが見つかったものと一致する場合にのみ、セッションが有効であると見なします。リモートクライアント。
このシナリオでは、攻撃者は次の 3 つのことを行う必要があります。
また、攻撃者が被害者のセッションを正しく乗っ取るために必要なすべてのことを攻撃者が知っているわけではないことを確認するのにも役立ちます。IE: Cookie だけが必要であると想定して失敗する可能性があります...そして、非常に長い試行錯誤を経て、他のすべてを理解しなければなりません。このようにして、攻撃者のスキルとシステムに関する彼/彼女の既存の知識に応じて、あいまいさと困難を通じてセキュリティを獲得します.
Bernd -- 標準の HTTP を介して何かを行う場合の問題は、それがプレーンテキストであることです。誰でも何でも偽造できます。IP スプーフィングは、単純な Cookie 盗用よりも実行が難しいため、IP への関連付けが一般的に行われています。あなたが言ったように、それは非常に動的な環境ではうまく機能しません。
私が考えることができる唯一の最も安全な方法は、HTTPS を使用して「永続的な」Cookie を配置および検証し、(同じ HTTPS セッションで) 短命のセッション Cookie を配置することです。残りの通信は、認証にセッション Cookie を使用して、通常の HTTP 経由で行うことができます。
そうすれば、暗号化をサポートするために使用されるリソースが少なくなり (ハンドシェイクのみ)、永続的な Cookie は公開されず (暗号化された状態でのみ送信されます)、セッション Cookie を盗んだ場合のリスクは限定されます。Cookie はすぐに期限切れになるためです。
とはいえ、本当に機密性の高いデータを含むサイトで、ユーザーに [remember me] をクリックさせないでください。だから銀行はそれをしない..
お役に立てれば。
複雑な Cookie ID と関連付けられた IP をデータベースに格納することについて -- 実際にはそうする必要はありません。秘密鍵 K を持っている場合、ユーザーの IP をあなたの K で暗号化し、結果の {IP}K を Cookie として配置するだけで十分です。あなたの鍵が安全である限り (そして暗号が破られていない限り - しかし、それが起こった場合、私たちはより大きな問題を抱えています)、これは安全です.
おそらく、リクエストごとに再生成されるセッション ID とトークン (IP、ソルト、およびセッション ID に基づくハッシュ) を使用する (高速ハッシュアルゴリズムを使用する) のが良い方法でしょうか? 私はセッション データをデータベースに保存しています (現在)。これは、リクエストごとに 2 つのクエリ オーバーヘッドがあることを意味します。それはこのように動作します：
このようにして、まず、トークンのベースとなるもの (この場合はリモート アドレス) に Cookie がバインドされます。それが盗まれてクライアント データが偽装された場合でも、Cookie は 1 つの要求に対してのみ有効です。傍受、それは役に立たない。
私が認識できる唯一の弱点は、攻撃者が Cookie を取得し、スプーフィングして、実際の人物が別のリクエストを行う前にそれを使用したかどうかです。これを解決するには、いくつかの方法を考える必要があります。オーバーヘッドは 2 つのクエリであり、トークン ハッシュを 2 回 (検証用に 1 回、置換用に 1 回) 生成します。
あいまいなIDであるCookieをローカルサーバーデータベースに保存します。Cookieで提供されたIDに基づいてサーバー側のDBルックアップを実行します。IDは、簡単に推測できないように十分に複雑にしてください。IDをユーザーのIPアドレスにマップします。IPが変更された場合は、強制的に再度ログインして、新しいIDを作成します。
2回目の読み取りでは、手をつないだ状態で高レベルのセキュリティが必要なようです。ユーザーは、ログインしたままにして、リスクを高めることを選択できる必要があります。アプリケーションとサーバーの観点から、世界中のすべてのセキュリティを実装できますが、ユーザーがティムホートンズ（カナダのスターバックス）のテーブルでラップトップを忘れた場合、どれも効果がありません。
ログインしたままにするかどうかはユーザーに任せ、情報が危険にさらされていることを警告します。
クッキージャーに蓋をします。
冗談はさておき、最善の選択肢はすでに述べられています - Cookie をあいまいな ID にし、それをサーバー側の IP アドレス検索に結び付けます。IPアドレスに関連付けることができないと編集したため、あいまいなID部分が残ります。Cookie を使用すると、オプションが制限されます。クライアントに何かを配置すると、リスクが生じます。
Bernd - IP アドレスを Cookie に接続することはオプションではないとおっしゃいましたが、ユーザーは DHCP 経由で接続できるため、毎回異なる IP でアクセスできると想定しています。Cookie を DNS ホスト名に関連付けることを検討しましたか? 秘密鍵を使用して Cookie を暗号化し、ユーザーのボックスに保存できます。次に、ユーザーが入ってくるたびに、Cookie をチェックし、暗号化を解除してから、ユーザーの現在の DNS ホスト名を Cookie 内のホスト名と照合します。一致する場合は、それらを許可します。一致しない場合は、自動ログインを許可しません。
参考までに - ASP.Net では、ユーザーのボックスの DNS ホスト名を取得するには、次を参照してください。
Page.Request.UserHostName