Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net/http: SameSiteDefaultMode adds an incorrect 'Set-Cookie' attribute #36990

Open
euank opened this issue Feb 3, 2020 · 4 comments
Open

net/http: SameSiteDefaultMode adds an incorrect 'Set-Cookie' attribute #36990

euank opened this issue Feb 3, 2020 · 4 comments

Comments

@euank
Copy link
Contributor

@euank euank commented Feb 3, 2020

Problem

Currently, http.SameSite offers the http.SameSiteDefaultMode option.

This is handled by code here:

go/src/net/http/cookie.go

Lines 220 to 229 in 07ccdeb

switch c.SameSite {
case SameSiteDefaultMode:
b.WriteString("; SameSite")
case SameSiteNoneMode:
b.WriteString("; SameSite=None")
case SameSiteLaxMode:
b.WriteString("; SameSite=Lax")
case SameSiteStrictMode:
b.WriteString("; SameSite=Strict")
}

For SameSiteDefaultMode, it adds SameSite (as a bare key, no =, no value) to the cookie.

On older versions of chrome, this results in the cookie being dropped entirely.

The draft specification for same-site makes it clear now that dropping the entire cookie is incorrect, but previously it implied this was correct behavior, so I wouldn't be surprised if this issue existed elsewhere too.

If the current draft spec is implemented correctly, SameSite would be parsed as an unrecognised value, and would then result in the samesite attribute it being ignored entirely (that is to say, being treated the same as http.SameSite(0) where nothing is added to the Set-Cookie header).

It seems a bit silly to include an option in the http library to generate an invalid cookie attribute which the browser should just ignore.

Possible Solutions

The 2 solutions that make sense to me are the following:

  1. Do nothing. We can document this possible issue with SameSiteDefaultMode and recommend not using it at all.
  2. Have SameSiteDefaultMode be the same as http.SameSite(0), where no SameSite attribute is included at all (which causes the browser to default to None or Lax, depending on version/browser).

I think option 2 ends up most closely matching what people would expect SameSiteDefaultMode to do. Technically it's a backwards incompatible change, which is the only reason I think we may wish to go with option 1 instead.

@euank euank changed the title http.SameSiteDefaultMode drops the entire cookie in some browsers http.SameSiteDefaultMode adds an incorrect 'Set-Cookie' attribute Feb 3, 2020
@odeke-em odeke-em changed the title http.SameSiteDefaultMode adds an incorrect 'Set-Cookie' attribute net/http: SameSiteDefaultMode adds a now incorrect 'Set-Cookie' attribute when previous spec implied it was correct Feb 5, 2020
@odeke-em

This comment has been minimized.

Copy link
Member

@odeke-em odeke-em commented Feb 5, 2020

Thank you for the report @euank!

Kindly paging some other experts @mikewest @vdobler.

@odeke-em odeke-em added this to the Backlog milestone Feb 5, 2020
@euank euank changed the title net/http: SameSiteDefaultMode adds a now incorrect 'Set-Cookie' attribute when previous spec implied it was correct net/http: SameSiteDefaultMode adds an incorrect 'Set-Cookie' attribute Feb 5, 2020
@euank

This comment has been minimized.

Copy link
Contributor Author

@euank euank commented Feb 5, 2020

I've reverted the title change because SameSite without a value was never correct as far as I can tell. My original comment was about how chrome's handling of that invalid value was technically correct, but that handling was for a case where the server sent the browser an incorrect cookie.

No matter what version of the spec we're going off, SameSite by itself isn't valid.. As best as I can tell anyway.

@vdobler

This comment has been minimized.

Copy link
Contributor

@vdobler vdobler commented Feb 13, 2020

@euank

No matter what version of the spec we're going off, `SameSite? by itself isn't valid.. As best as I can tell anyway.

I took a look at https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00#section-3.1
which defines the Set-Cookie header field:

samesite-av    = "SameSite" / "SameSite=" samesite-value
samesite-value = "Strict" / "Lax"

As you can see a single "SameSite" was okay.

But you are right it seems as if this was changed in https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-05#section-4.1.1 :

samesite-av       = "SameSite=" samesite-value
samesite-value    = "Strict" / "Lax" / "None"

So it does matter which spec we try to implement.

Is far as I understand the Chromium sources and the spec 6265bis-05 a "naked" SameSite would lead to dropping the samesite-av which then is treated as None (from 6265bis-05: "Note: This algorithm maps the "None" value, as well as any unknown value, to the "None" behavior, which is helpful for backwards compatibility when introducing new variants.").

So we a) should document the issue with SameSiteDefaultMode but b) we do not need to change how SameSiteDefaultMode is serialized (as it will be treated as None).

@euank

This comment has been minimized.

Copy link
Contributor Author

@euank euank commented Feb 13, 2020

@vdobler

I took a look at https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00#section-3.1
which defines the Set-Cookie header field:

samesite-av    = "SameSite" / "SameSite=" samesite-value
samesite-value = "Strict" / "Lax"

As you can see a single "SameSite" was okay.

Yeah, that version sorta implies it's okay, but then section 4.1 makes it clear that it expects a attribute-value, so other parts of the document do kinda imply it's invalid.. And as you point out, more recent spec versions do remove that.

I think overall what you've said makes sense, though with two additional caveats:

  1. Chromium and firefox both intend to move to Lax by default, which I think will also apply to SameSite by itself, so it's not identical to None.
  2. Per the link in my first comment, older versions of chrome did have an incorrect behavior and dropped the entire cookie.

The reason I became aware of this issue in the first place is that we had users that ran into cookie issues with our site due to an incidental use of SameSiteDefault, so there's evidence at least some people are on chrome versions where this option does break things. Specifically, some android 8 users ran into issues.

Because of the above, it seems like serializing it as nothing, rather than as SameSite, has an identical behavior in all well-behaved browsers, but on at least one browser (older chrome) avoids a bug.

I think the best thing to do is add a comment indicating you should never use that const, and should rather use http.SameSite(0) to get the default behavior of the browser.

I'm happy to open a CR for that if it sounds good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.