secure
フラグを持つクッキーは、暗号化されていない接続を介して送信されないことがわかりました。どのようにこれが深く働くのだろうか。クッキーの「セキュア」フラグはどのように機能しますか?
クッキーを送信するかどうかを決定するのは誰ですか?この暗号化された接続のために、これだけ
secure
フラグを持つクッキーは、暗号化されていない接続を介して送信されないことがわかりました。どのようにこれが深く働くのだろうか。クッキーの「セキュア」フラグはどのように機能しますか?
クッキーを送信するかどうかを決定するのは誰ですか?この暗号化された接続のために、これだけ
クライアントのセットがRFC 6265に定義されています。
セキュア属性がチャンネルを「確保」するためにクッキーの有効範囲を制限し(ここで、「安全な」ユーザエージェントによって定義されます)。 CookieにSecure属性がある場合、ユーザーエージェントは、要求が安全なチャネル(通常はTLS(Transport Layer Security)[RFC2818]経由のHTTP)を介して送信される場合にのみ、HTTP要求にCookieを含めます。
アクティブネットワーク侵入者からのクッキーを保護するためには一見役立ちますが、Secure属性はクッキーの機密性のみを保護します。アクティブなネットワーク攻撃者は、セキュアでないチャネルからのセキュアなCookieを上書きして、その完全性を中断させることができます(詳細は8.6節を参照)。件名に
ちょうど別の単語:あなたのウェブサイトexample.com
が完全にHTTPSであるため、
がsecure
を省略するには十分ではありません。
ユーザーが明示的にhttp://example.com
に達している場合、彼はhttps://example.com
にリダイレクトされますが、遅すぎます。最初のリクエストにはCookieが含まれています。
クライアントサイドにまだクッキーがなく、サーバサイドから(例えばログインして)送信する必要がある場合は、サーバ側がそれに応じてクッキーを含めることにしますか? – ted
サーバーは最初に "Set-Cookieヘッダー"を使ってCookieを設定します – Ivan