I know that a cookie with secure flag won't be sent via an unencrypted connection. I wonder how this works in-depth.
Who is responsible for determining whether the cookie will be sent or not?
-
Note: this "Secure" flag is only just one layer in defense in depth - an attacker is still able to write to a "Secure" cookie if they can MITM, and this has the potential to lead to a session fixation attack - this related thread asked how and I provided an in-depth answer on how this is done, plus how this may be mitigated (HSTS can work, but also a specific name prefix can be used together to fully mitigate this).metatoaster– metatoaster2023-06-13 10:30:20 +00:00Commented Jun 13, 2023 at 10:30
Add a comment
|
2 Answers
The client sets this only for encrypted connections and this is defined in RFC 6265:
The Secure attribute limits the scope of the cookie to "secure" channels (where "secure" is defined by the user agent). When a cookie has the Secure attribute, the user agent will include the cookie in an HTTP request only if the request is transmitted over a secure channel (typically HTTP over Transport Layer Security (TLS) [RFC2818]).
Although seemingly useful for protecting cookies from active network attackers, the Secure attribute protects only the cookie's confidentiality. An active network attacker can overwrite Secure cookies from an insecure channel, disrupting their integrity (see Section 8.6 for more details).
Just another word on the subject:
Omitting secure because your website example.com is fully https is not enough.
If your user is explicitly reaching http://example.com, they will be redirected to https://example.com but that's too late already; the first request contained the cookie.
10 Comments
Mr. MonoChrome
I know this is old, but HSTS preload helps this situation by preventing this problem from occurring frequently. Its still not 100% fix but its just another thing to consider if you really want to avoid secure cookie.
MEMark
@Mr.MonoChrome Why would you want to avoid secure cookie?
piris
Good point. For .NET applications it is better to do the redirect in IIS (or web.config) rather than programmatically (for example globals.asax)
Alain
@braks sure, but accessing your website on port 80 would give a connection refused, and browsers/users don't expect that.
Alain
@DavidB yes, for the very reason i given above.
|