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

[euank]

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.

[odeke-em]

Thank you for the report @euank!

Kindly paging some other experts @mikewest @vdobler.

[euank]

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]

@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]

@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.

[empijei]

Drive-by comment: I would also be inclined to make it serialize as nothing. There is not benefit in adding SameSite with no = and I fear the spec ambiguity might just cause issues.

(I got here because I found this issue myself and was about to open a duplicate)

[FiloSottile]

In packages that target a moving platform, like net/http and the Web Platform or crypto/x509 and the Web PKI, we should interpret the backwards compatibility promise in terms of behaviour, not wire output.

So agreed that if the naked option was dropped and the way to get the default is to serialise nothing, then that option should be changed to serialise nothing.

[gopherbot]

Change https://golang.org/cl/256498 mentions this issue: net/http: make SameSiteDefaultMode behavior match the specification

[pjediny]

@empijei @FiloSottile @euank I disagree. This would downgrade security for older browsers like iOS Safari, as you can see they interpret missing attribute value as Strict (see this), and this patch would just downgrade the behavior to missing SameSite attribute. The older standard defaults to Strict, only the new one defaults to None.

I would suggest to keep the old behavior (revert this patch), despite the name, it is not a real default so it was used deliberately and let the browsers interpret the attribute. Maybe consider #39610 to have a name for the real default (zero value) too.

[euank]

@pjediny I filed this issue because gorilla/csrf assumed the 'Default' value was the right value for backwards compatibility, which led to a regression in some code using it when we upgraded go.

I don't think people were deliberately using the 'Default' value to get 'Lax' on some browsers (newer chrome/ff I think), 'None' on other browsers (older chrome/ff), 'strict' on other browsers (apparently ios), and silently drop the cookie on yet other browsers (some older chrome/android).

That was the previous behavior of 'Default' if I understand all this correctly.

If people deliberately wanted to set 'Strict', they would have set 'Strict'.

[pjediny]

@euank So instead of fixing gorilla/csrf you would rather change the behavior for all and instead of browser default interpretation you would enforce behavior that suits your case with no regard to backward compatibility.

If the people didn't want SameSite attribute without a value to be set, they should have not set it.

While I agree that the situation is quite a mess and the name is unfortunate and confusing, changing the behavior to something else adds to this mess too. Now we need to keep track of not only browser versions/implementations but the go versions too.

• Now, when I want the SameSite without a value (for example for a testing tool) with the current API, I'm not able to do it.
• It breaks security expectations on some used browsers (old safari)
• It's a silent behavior change - I would prefer deprecation, removal (with adding some new flexible cookie API) and loudly breaking builds, in the end it's security related
• It tries to do a browser job (interpret what the user agent should do with such attribute)

On the other hand, it's old draft vs new draft...

[euank]

I think we're on a similar page overall, @pjediny. gorilla's use was fixed, I'm just pointing out that the value 'Default' as it was implemented before has caused actual breakages for people.

I agree there's some bad cases with either option. You're right that this is a subtly backwards incompatible change, though for most cases it seems like it'll be a strict improvement, and other parts of the http stack make technically-backwards-incompatible-changes all the time (like http.Get suddenly defaulting to http2 when you update go). The http package as a whole does not maintain wire-level backwards compatibility.

To me, the most compelling reason is that SameSiteDefault to me doesn't imply that a user should have an expectation of security, so the fact that there's an edge case where it reduces security is less important.
It implies to me much more strongly that SameSiteDefault is a valid value for SameSite. The change makes that true. Before the change, that wasn't totally true; it was a value that was valid for a subset of browsers, but in the wild there existed browsers it just broke badly.

[pjediny]

I see. We agree, but we disagree on how a solution to such problem should look like.

The biggest issue is the confusing mode name, but maybe there were some other solutions to this problem:

• better documentation
• deprecation/removal process
• change of the mode behavior
• combination with retaining the old behavior under different mode name, to keep the 'silly' ability

Default is probably now closer to what one would expect, but I find it in some ways still a little confusing.

I'm not sure if it can revert the decision or not, but I probably cannot do much more than to state these impacts and propose other solutions. Thanks for patience anyway.

[empijei]

My 2c on this:

• Supporting older browsers is fine as long as we do not damage functionality in some other browsers. The behavior described by @euank sounds like a nightmare to debug and relies too heavily on web platform quirks

using the 'Default' value to get 'Lax' on some browsers (newer chrome/ff I think), 'None' on other browsers (older chrome/ff), 'strict' on other browsers (apparently ios), and silently drop the cookie on yet other browsers (some older chrome/android).

• The http package tries to implement the spec, and when that changes we have to move forward if the vast majority of browsers does. I don't want users to set the default value expecting to increase security when instead they will get absolutely no benefit.
• WRT deprecation, we could indeed deprecate SameSiteDefault, wanna create a CL to add the Deprecated: reason doc line?
• What would be the value in keeping the old behavior? When you say "old iOS Safari", how old are we talking about?
• Would have you preferred to have "lax" instead of "none" as default? Because if this is the case we would have risked breaking many users, which I'm not willing to commit to.

[pjediny]

What would be the value in keeping the old behavior? When you say "old iOS Safari", how old are we talking about?

Safari&webviews on iOS 12 (iPhone6 latest iOS). The 'none' attribute value is not supported and the browser handles it as 'strict' instead...

Would have you preferred to have "lax" instead of "none" as default? Because if this is the case we would have risked breaking many users, which I'm not willing to commit to.

I was thinking about this a little bit more, currently I have something close to proposal:

Cookie write mode

• I would prefer not to have a name of mode with default in it - so deprecated and removed in the future releases, but keep the old behavior under this name for now
• Default behavior itself should be a zero value, that is interpreted as SameSite attribute completely missing from the cookie
• The zero value mode should have a name (check net/http: add SameSiteUnsetMode const #39610), SameSiteUnsetMode
• Deprecation of default mode should add a new mode name with the old default mode behavior to retain ability to have SameSite attribute present, but without a value. The mode name could be something like SameSiteNoValueMode
• Maybe fix the reference https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00 in the sourcecode to something newer

Cookie read mode

• The unknown attribute value should be interpreted as SameSiteNoneMode and not SameSiteDefaultMode like it is interpreted now
• +review cookie jar handling

What do you think about it?

• this would remove SameSiteDefaultMode name ambiguity
• keeps old draft capability
• handles new draft properly
• handles zero value idiomatically

If there is an agreement, I'm willing to create the CL.

[FiloSottile]

'Lax' on some browsers (newer chrome/ff I think), 'None' on other browsers (older chrome/ff), 'strict' on other browsers (apparently ios), and silently drop the cookie on yet other browsers (some older chrome/android)

I don't see why anyone would ever want this behavior, and I don't think we need to support it.

We should definitely update the spec reference in the docs.

Deprecating SameSiteDefaultMode is also a good idea, but we are not going to remove it. Deprecation is how we tell applications they need to actively move away from something.

A name for the zero value also sounds good. I'd call it SameSiteUnset, without Mode.

When parsing we should do what modern browsers do. What is that?

[empijei]

Modern browsers ignore any SameSite attribute that doesn't have a value or that has an unknown value so we should probably do the same and set it to the new proposed Unset value.

+1 on Deprecating
+1 on updating the spec
+1 on having a name for the Unset value
-1 on supporting the old behavior, I think if you are doing User-Agent sniffing on the server side and detect a very old browser you can just disable SameSite completely for that specific request. This is what most servers already do when they see unsupported user agents and serves as a good driver to make vendors implement or backport new specifications. I personally don't thing it does any good to keep supporting platforms that have stopped receiving updates from their own producers.

If this is good enough for you, you might want to try and take a stab at this.

[pjediny]

@FiloSottile

'Lax' on some browsers (newer chrome/ff I think), 'None' on other browsers (older chrome/ff), 'strict' on other browsers (apparently ios), and silently drop the cookie on yet other browsers (some older chrome/android)

This is a little bit unfair, it is mixing standard evolution steps (that will stay) and browser bugs.

I don't see why anyone would ever want this behavior, and I don't think we need to support it.

I do see a little bit of a value for compliance/pen testing tools. I understand it is not a common use, so you will probably not want to support it, but it was possible to use it before and now there is no clear path to replace it. Maybe there are some other use cases, that we don't know about.

We should definitely update the spec reference in the docs.

Maybe the https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-06#section-5.3.7 is now the appropriate reference.
As it will expire October 22, 2020 should we wait if the new draft will appear?

Deprecating SameSiteDefaultMode is also a good idea, but we are not going to remove it. Deprecation is how we tell applications they need to actively move away from something.

This will need a clarification

• Do you want to keep the old behavior and deprecate or to keep the new behavior and add the deprecation notice to it?
• If the old behavior is removed, why the mode name should not be (this is a discussion we could have later)

A name for the zero value also sounds good. I'd call it SameSiteUnset, without Mode.

I think this is a good idea. I was thinking about it, but the all the names are of the SameSite<Name>Mode form. Is there an example in the go project of such double name form for enumeration constants?

When parsing we should do what modern browsers do. What is that?

Standard says unknown values should enforce 'None' behavior. There are multiple issues with this:

• It's an unsafe default (but it was needed for backward compatibility)
• The newest versions of browsers allow 'None' mode only for secure cookies (IIRC http only cookies over secure channel)
• Ambiguity with standalone SameSite attribute and SameSite attribute value pair, where the standalone case could be interpreted as unknown value => None over secure channel or as invalid attribute => interpreted as cookie without any samesite and enforced as Lax mode.

@empijei

Modern browsers ignore any SameSite attribute that doesn't have a value or that has an unknown value so we should probably do the same and set it to the new proposed Unset value.

I believe this is incorrect. See above, default for unknown is None enforcement for backward compatibility, we will probably need something like SameSiteValueUnknownMode to distinguish between the unset attribute and unknown attribute value to select proper enforcement in the client.

+1 on Deprecating
+1 on updating the spec
+1 on having a name for the Unset value
-1 on supporting the old behavior, I think if you are doing User-Agent sniffing on the server side and detect a very old browser you can just disable SameSite completely for that specific request. This is what most servers already do when they see unsupported user agents and serves as a good driver to make vendors implement or backport new specifications. I personally don't thing it does any good to keep supporting platforms that have stopped receiving updates from their own producers.

I strongly disagree. As example can be Google making this mess with SameSite=None, forced the new behavior too soon and Apple did not backport. Rumor says Google was not able to deploy own SSO services in time not to break with (not only) Apple browsers, so enforcement had to be postponed anyway. Third parties were made to make hackish workarounds with User-Agent sniffing (unreliable) and double cookie sends (overhead) to be able to work with new Chrome and not so 'old' Safari.

While I agree with the goal, the way it was forced feels just wrong. It was in the situation when the standard draft was hastily edited (and now it shows how ambiguous and underspecified it is), the problem it was handling had already known mitigations deployed.

I'm not sure what makes this inconsiderate behavior so seductive in Google, it may be the mono repo development style or the Chrome marketshare of the web platform, but it is causing problems for external vendors.

If this is good enough for you, you might want to try and take a stab at this.

If there is no rush, let's wait for replies for few days, maybe new draft. I'm now thinking about enforcement and attribute value separation in read/write modes and still want to review how the cookie jars are handled.

How much do we hurry/can we get this in go1.16?

[empijei]

forced the new behavior too soon and Apple did not backport

The fact that on Apple browsers SameSite=None behaved as SameSite=Lax was a bug, it's not really about backporting but more like Apple not really caring about what FF and Chrome do or what the spec says (aka: unknown values should be ignored). Nowadays Safari enforces something similar to SameSite=Lax by default and they pushed it to all users in a completely careless way, not putting much thought about breakages and bragging about having solved CSRF (which they didn't). They can because the user base is small and people can always count on compliant, backup browsers in case stuff doesn't work.

so enforcement had to be postponed anyway

Yes, it was because the breakage would have been too big since Apple was lagging too much behind (two full years) the current spec and, unlike the expectation towards Safari, people rely on Chrome to always work.

I'm not sure what makes this inconsiderate behavior so seductive in Google

My personal guess: trying to protect users from CSRF in a widespread way, since the issue has been there for very long it would just be inconsiderate to leave that dangerous issue there when there is a way for user agents to fix it (exactly like Safari did, please see the the links above). Please note this is a personal guess and not an official Google stance.

I strongly disagree
How much do we hurry/can we get this in go1.16?

I am fine with rolling back my change and keep discussing this here, I am not in a rush to get this fixed and I would like to find something that works for everyone.

If I get this right your proposal is:

• The SameSiteDefault value will keep its current behavior when cookies are set, but the value will have a deprecation note that explains why this should not be used for modern browsers.
• We add SameSiteUnknown and SameSiteUnset values that will only be used during parsing. SameSiteDefault will not be used during parsing

My question would be: if someone wrote a server 3 years ago and used SameSiteDefault their intention would have been to use what today is called SameSiteLax. How do we make it so that code, when run with modern versions of Go and modern browsers maintains the intended behavior?

[rsc]

@FiloSottile @empijei I am confused about the state of this issue and want to make sure we don't make a change in Go 1.16 that we do not intend to make.

Should https://go-review.googlesource.com/c/go/+/256498 be rolled back?

[empijei]

We could roll that back until we reach a consensus or fix-forward. This is not a big issue either way.

[pjediny]

There is a new development regarding this. New rfc6265bis draft (07) introduces a Default enforcement.

[FiloSottile]

   4.  If the cookie-av string contains a %x3D ("=") character:

       [...]

       Otherwise:

       1.  The attribute-name string consists of the entire cookie-av
           string, and the attribute-value string is empty.

   If the attribute-name case-insensitively matches the string
   "SameSite", the user agent MUST process the cookie-av as follows:

   1.  Let "enforcement" be "Default".

   2.  If cookie-av's attribute-value is a case-insensitive match for
       "None", set "enforcement" to "None".

   3.  If cookie-av's attribute-value is a case-insensitive match for
       "Strict", set "enforcement" to "Strict".

   4.  If cookie-av's attribute-value is a case-insensitive match for
       "Lax", set "enforcement" to "Lax".

   5.  Append an attribute to the cookie-attribute-list with an
       attribute-name of "SameSite" and an attribute-value of
       "enforcement".

(The next paragraph says the algorithm maps unknown values to "None" but it clearly maps to "Default", so I am going to assume it's an editing mistake.)

Awesome. This looks like exactly our post-CL 256498 behavior, and the fact that the spec is calling this Default probably saves us renaming/deprecating it. So in theory we are now spec compliant. In practice, the current behavior also seems to match what applications would want (as opposed to risking Strict on iOS, dropped on some browsers, and Default on the rest). I think CL 256498 is fine, and there is no more work left. Please correct me if I'm wrong.

[pjediny]

Unknown should map to None, without Unkown->None mapping you don't have backward compatible behavior. Default is just indirect reference to Lax. Bad editing as you noted. It just boils down to difference between the enforcement and actual attribute value. For example the value could be None but the enforcement would be Lax (default) when the Secure attribute is not set. I would not be closing this yet.

   *  Add a default enforcement value to the "same-site-flag",
      equivalent to "SameSite=Lax": https://github.com/httpwg/http-
      extensions/pull/1325 (https://github.com/httpwg/http-extensions/
      pull/1325).

   *  Require a Secure attribute for "SameSite=None":
      https://github.com/httpwg/http-extensions/pull/1323
      (https://github.com/httpwg/http-extensions/pull/1323).

   *  Consider scheme when running the same-site algorithm:
      https://github.com/httpwg/http-extensions/pull/1324
      (https://github.com/httpwg/http-extensions/pull/1324).

[FiloSottile]

httpwg/http-extensions#1325 looks very clear to me that unknown maps to Default, and they just omitted to change the paragraph below the algorithm. Opened httpwg/http-extensions#1339 to clarify.

[pjediny]

Yop, you are probably right about this one. Citing the https://tools.ietf.org/html/draft-west-cookie-incrementalism-01#section-3.1
now when modern browsers support None values, they want to move from unsafe default.

   This would have the effect of mapping the default behavior in the
   absence of an explicit "SameSite" attribute, as well as the presence
   of any unknown "SameSite" value, to the "Lax" behavior, protecting
   developers by making cross-site delivery an explicit choice, as
   opposed to an implicit default.

Still, it's a user agent perspective, the server side could be more flexible.

[FiloSottile]

I'd rather err on the side of least surprise and of better security. If the application uses SameSiteDefault, they'd be surprised to generate SameSite=None when Default is defined in the spec to be a more secure option.

[euank]

For what it's worth, I think the already-merged CL 256498 is my preferred solution.
It fixes the problem I ran into that caused me to file this issue, so from my perspective, I'm happy for this issue to be closed as solved with go1.16.

Thanks for the help getting this fixed, @FiloSottile!

[pjediny]

I have this feeling we misunderstand each other, I'm afraid we somehow mix the mode request and user agent enforcement and IMO you lean too much on the UA side interpretation. I'm not aware I was requesting SameSite=None to be the DefaultMode behavior, I wanted to keep the old behavior and/or rename the mode as the name was confusing.

We only have three modes of UA behavior: None, Lax, Strict but we have more than three ways to request them (+unset, orig Default and complication with the Secure attribute).
If I stretch this situation a little bit, modern UAs do not "support" cookies without SameSite set, they will interpret them as SameSite=Lax instead. Does it mean we should disable sending cookies without samesite/set with lax from server side too? It looks very similar to me.
Or something more in spec like sending None without the Secure attribute. I think considerations what to do with such cookies should be made on clientside with something like cookiejar.

I still disagree, but it looks like you converged on already merged solution and the SameSite w/o value is not supported by current specs and usecase is kind of marginal so I will stop nagging people on this issue. Thank you and I hope I did not waste too much of your time.

[FiloSottile]

Thank you and I hope I did not waste too much of your time.

You definitely didn't waste anyone's time, thank you for the discussion, it helped make sure we all understood what was going on, even if we did not end up agreeing on the exact same outcome.

[gopherbot]

Change https://golang.org/cl/288274 mentions this issue: net/http: adapt SameSiteDefaultMode behavior match the specification