ロードバランサーのために安全でないCookie
Httpへのhttpsリクエストを終了するロードバランサーがあるので、バックエンドサーバーはそれらをhttpとして認識します。その結果、このサイトのhttpsバージョンでCookieを表示すると、すべてのCookieに安全なフラグが設定されていません。 httpとhttpsを混在させているので、これは問題になりますか？ Amazon.comや他のいくつかの大規模なeコマースサイトでは、httpsにも安全でないcookieが含まれているようです。
Cookieは、「セキュア」フラグを持っている場合はそれを持っています。理論的には、「安全な」CookieがHTTP（非HTTPS）サーバーによって提供されるのを妨げるものは何もありません。ただし、その観点から見ると、プロトコルはHTTPであり、安全なCookieがHTTP経由で転送される場合はほとんど意味がないため、サーバーソフトウェアが問題を起こす可能性があります。サーバーは、HTTPSからHTTPへのゲートウェイの背後にあることを認識していません。一方、クライアントはHTTPS接続を認識し、そのような接続を介して安全なCookieを取得しても、驚くことはありません。
安全でないcookieの問題は、クライアントが元のサーバーのように見える任意のサーバーに喜んで送信することです。アクティブな攻撃者がいる場合、セキュリティで保護されていないCookieが攻撃者に乗っ取られる可能性があると想定する必要があります。正確な状況に応じて、これはメジャー、マイナー、または存在しない脅威になる可能性があります。
セッションCookieの; secureフラグは重要です。Cookieはhttp経由で送信されるためです。すべてのリンクとリソースをhttpsにポイントしても、攻撃者は被害者をだましてhttp接続を開かせることができる場合があります。
通常は、アプリケーションサーバーに; secureフラグを設定するように機能します。ロードバランサーはhttps接続内で応答を返すだけで、クライアントはすべて問題ありません。主な問題は、アプリケーションサーバーへのhttp接続にCookieを含めるようにロードバランサーに指示することです。ロードバランサーの具体的な実装によって、自動的に行われるか、構成が必要かによって異なります。
はい、それは重要です。セキュアフラグがこれらのCookieに設定されていない場合、Firesheepのような攻撃に対して脆弱であり、これはユーザーに悪影響を与える可能性があり、悪影響を及ぼす可能性があります（特に、オープンワイヤレス接続を介して接続しているユーザーなど）。したがって、これらのCookieにセキュアフラグが設定されていることを確認することをお勧めします。
から wikipedia
安全なCookieは、ブラウザがHTTPS経由でサーバーにアクセスしているときにのみ使用されます。これにより、クライアントからサーバーへの送信時に常にCookieが暗号化され、盗聴によるCookieの盗難にさらされる可能性が低くなります。
したがって、答えは本当に、http経由で送信されるCookieのコンテンツを心配しているのか、それともデータに敏感であり、常にhttps経由で送信する必要があるのかということです。