2

As I understand it, the SameSite attribute for cookies helps me advise standard browsers what they can do with them.

So if I'm a server running on http://acme.com/my-app and I've set a cookie like:

Set-Cookie: JSESSIONID=1234567890abcdef; SameSite=Strict

If the user is on https://www.facebook.com, the browser will stop it from sending me requests with the cookie JSESSIONID (for fear of them executing malicious code).

If I want my cookie to be used for cross-site requests I need to set SameSite to None (which used to be default but is now Lax).

However, browsers also require that cookies with this attribute also have the attribute Secure (example from the docs):

Set-Cookie: flavor=choco; SameSite=None; Secure

What I don't understand is why. I understand why SSL connections are more secure and why we would prefer both SSL and the attributes SameSite=Strict and Secure for our cookies where possible.

But why enforce Secure only for cross-site cookies and not for all cookies? It obviously doesn't prevent any website using the cookie to execute requests (that's what SameSite is for). So https://evil-evil.com can just as easily send me the user's SameSite=None cookies as https://facebook.com. Sure, we prevent snooping and third-party monitoring (man-in-the-middle), but we also have that problem for SameSite=Strict cookies. I.e. the bad people can still steal the cookies I send over the insecure http://acme.com/my-app/perform-sensitive-action.

So why enforce Secure for some types of cookies except that Google said so?

Druckles
  • 153
  • 3

1 Answers1

3

This is a privacy measure intended to mitigate pervasive monitoring of network traffic by ISPs, governments, and other network actors.

The motivation is explained in detail in section 3.2 of the IETF draft [draft-west-cookie-incrementalism-01]:

Requiring "Secure" for "SameSite=None"

Cookies sent over plaintext HTTP are visible to anyone on the network. As section 8.3 of [RFC6265bis] points out, this visibility exposes substantial amounts of data to network attackers. We know, for example, that long-lived and stable cookies have enabled pervasive monitoring [RFC7258] in the past (see Google's PREF cookie [pref-cookie]), and we know that a secure transport layer provides significant confidentiality protections against this kind of attack.

We can, to a reasonable extent, mitigate this threat by ensuring that cookies intended for cross-site delivery (and therefore likely to be more prevalent on the wire than cookies scoped down to same-site requests) require secure transport.

As for why this isn't enforced for all cookies, that's likely a compromise intended to balance the privacy improvements of secure cookies against the harm of breaking existing plaintext HTTP sites that rely on first-party cookies. As HTTPS adoption on the web becomes more widespread, it's possible browsers may eventually move to restrict cookies entirely to secure contexts.

Ajedi32
  • 4,637
  • 2
  • 26
  • 60
  • Thank you, that helps somewhat. What I still don't quite understand is "therefore likely to be more prevalent on the wire." Why is that the case for cross-site cookies more than same-site? – Druckles Aug 11 '21 at 08:10
  • 2
    @Druckles It means cross-site cookies get sent/received more frequently than first-party cookies, so there's more opportunity for them to be intercepted by attackers. Cross-site cookies are often used for things like ad targeting and social media share buttons, so unlike first party cookies they get sent a lot even when you aren't using the site they're set for. – Ajedi32 Aug 11 '21 at 13:39