Use browser 2020 recommendations for SameSite cookie rules #5293

summercms · 2020-10-01T12:10:53Z

The browsers have been rolling this out for a few weeks now, see more info here: https://www.chromium.org/updates/same-site

Aug 11, 2020
The target rollout population has been increased to 100% of users on Chrome Stable versions 80 and above, and the actual proportion of users with the new behaviour enabled is now ramping up to 100% gradually. Users will receive the new behaviour when they restart Chrome.

The old pr was here: #4881 this pr was created as the branch was missing.

Tag admins and reviewers: @LukeTowers @daftspunk @RodrigoGalter

Question 1

Why did we choose Lax as the October CMS as the default?

Answer 1

See comments below.

You may also want to consider using Strict to enhance privacy and security even more.

Question 2

Can I use Strict, Lax or None on other cookies on the October website?

Answer 2

Yes, you can! The October CMS session cookie can be set to Lax and another cookie can have a different setting. Each cookie has it's own settings.

Question 3

What about sub-domains?

Answer 3

All modern browsers are now using the cross-origin API rules, you can see a summary here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Resource-Policy

The SameSite API uses the cross-origin API rules! Browsers will treat a cookie on the main domain and sub-domains with the exact same rules!

Question 4

Will browsers have issues if people specify any of these options as lower-case?

Answer 4

No browsers wont have a problem if people write it as lower case and I have tested it in Chrome and Firefox in the past (as I also wondered that). The reason I write the first letter as a capital is because all the examples in Chrome, Edge and Firefox are written like that. So I decided to copy them and write them the same as the examples. Also the source code in Chromium is written with a first capital letter.

Question 5

What happens in modern browsers when same-site is set to null?

Answer 5

Chrome, Microsoft Edge and Firefox set the cookie internally to Lax, I'm not sure what Safari does. You can see the following browser issues for more details:

https://groups.google.com/g/mozilla.dev.platform/c/nx2uP0CzA9k/m/BNVPWDHsAQAJ?pli=1

https://docs.microsoft.com/en-us/microsoft-edge/web-platform/site-impacting-changes

https://bugzilla.mozilla.org/show_bug.cgi?id=1551798

Also as per the spec:

First, cookies should be treated as
"SameSite=Lax" by default. Second, cookies that explicitly assert
"SameSite=None" in order to enable cross-site delivery should also be
marked as "Secure". Third, same-site should take the scheme of the
sites into account. Fourth, cookies should respect schemes. Fifth,
cookies associated with non-secure schemes should be removed at the
end of a user's session. Sixth, the definition of a session should
be tightened.

The important bit is: First, cookies should be treated as "SameSite=Lax" by default.

Link: https://tools.ietf.org/html/draft-west-cookie-incrementalism-01

Testing

We have been using the following setup for over a year now without any issues on over 300 October websites now:

HttpOnly = True
Secure = True
SameSite = Lax

This is the recommended setup! If you are using October CMS as an API then please see the notes about Third-Party settings.

`Google Chrome` Cookie Legacy SameSite Policies

NOTE: These policies available as of Chrome 79.

These policies will be available until at least July 14, 2021. We will be monitoring feedback about these policies and will provide updates on their lifetime as appropriate.

The policies LegacySameSiteCookieBehaviorEnabled and LegacySameSiteCookieBehaviorEnabledForDomainList allow you to revert the SameSite behavior of cookies (possibly on specific domains) to legacy behavior.

All cookies that match a domain pattern listed in LegacySameSiteCookieBehaviorEnabledForDomainList (see below) will be reverted to legacy behavior. For cookies that do not match a domain pattern listed in LegacySameSiteCookieBehaviorEnabledForDomainList, or for all cookies if LegacySameSiteCookieBehaviorEnabledForDomainList is not set, the global default setting will be used. If LegacySameSiteCookieBehaviorEnabled is set, legacy behavior will be enabled for all cookies as a global default. If LegacySameSiteCookieBehaviorEnabled is not set, the user's personal configuration will determine the global default setting.

The SameSite attribute

The SameSite attribute of a cookie specifies whether the cookie should be restricted to a first-party or same-site context. Several values of SameSite are allowed:

A cookie with "SameSite=Strict" will only be sent with a same-site request.
A cookie with "SameSite=Lax" will be sent with a same-site request, or a cross-site top-level navigation with a "safe" HTTP method.
A cookie with "SameSite=None" will be sent with both same-site and cross-site requests.

See https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-4.1.2.7 for the definition of the SameSite attribute. See https://web.dev/samesite-cookies-explained/ for a more detailed explanation of the SameSite attribute with examples.

Schemeful Same-Site

Schemeful Same-Site is a modification of the definition of a “site” to include both the scheme and the registrable domain. This means that, with Schemeful Same-Site, http://site.example and https://site.example are now considered cross-site whereas previously they would be considered same-site.

This feature is still being prototyped and has a tentative M88 launch. See Chrome Platform Status page.

See the Schemeful Same-Site explainer for more details and examples.

See https://mikewest.github.io/cookie-incrementalism/draft-west-cookie-incrementalism.html#rfc.section.3.3 for the spec.

Legacy SameSite behavior

As of Chrome 80, a cookie that does not explicitly specify a SameSite attribute will be treated as if it were "SameSite=Lax". In addition, any cookie that specifies "SameSite=None" must also have the Secure attribute. (See https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-4.1.2.5 for the definition of the Secure attribute.)

Reverting to the legacy SameSite behavior causes cookies to be handled like they were prior to May 2019 (when the new SameSite behavior described above first became available). Under legacy behavior, cookies that don't explicitly specify a SameSite attribute are treated as if they were "SameSite=None", i.e., they will be sent with both same-site and cross-site requests. In addition, reverting to the legacy behavior removes the requirement that "SameSite=None" cookies must also specify the Secure attribute. As of Chrome 86 reverting to legacy behavior will also disable Schemeful Same-Site.

Configuring LegacySameSiteCookieBehaviorEnabledForDomainList

In this policy setting, you can list specific domains for which legacy SameSite behaviour will be used.

The domain of a cookie specifies those hosts to which the cookie will be sent. If the Domain attribute of the cookie is specified, then the cookie will be sent to hosts for which the specified Domain attribute is a suffix of the hostname, and reversion to legacy SameSite behaviour will be triggered only if the value of the specified Domain attribute matches any of the patterns listed in this policy setting. If the Domain attribute of the cookie is not specified, then the cookie will only be sent to the origin server which set the cookie, and reversion to legacy SameSite behaviour will be triggered only if the hostname of the origin server matches any of the patterns listed in this policy setting. See https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-4.1.2.3 for the definition of the Domain attribute.

Example 1: If the Domain attribute of the cookie is set to "Domain=example.com", the cookie will be sent when making HTTP requests to example.com, www.example.com, or www.corp.example.com. To revert to legacy behaviour for such a cookie, use the pattern [*.]example.com or example.com. The value of the Domain attribute (example.com) will match either of these patterns. Even though the cookie would be sent to www.example.com, the pattern www.example.com will NOT match such a cookie, because the Domain attribute value (example.com) does not match the pattern www.example.com.

Example 2: If the Domain attribute of a cookie set by www.example.com is not specified, the cookie will be sent only when making HTTP requests to www.example.com. The cookie will not be sent when making HTTP requests to example.com or sub.www.example.com. To revert to legacy behaviour for such a cookie, use the pattern www.example.com or [*.]example.com. The origin server's hostname (www.example.com) will match either of these patterns.

Note that patterns you list here are treated as domains, not URLs, so you should not specify a scheme or port. Specifying a scheme or port may result in undefined behaviour.

Browser Timeline Notes

Chrome: 84.0.4147 (stable) Released: 2020-07-14 - Same Site Cookie policy changes are starting to roll out again
Chrome: 85.0.4183 (stable) Released: 2020-08-25 - Rejection of insecure SameSite=None cookies
Firefox 75 (stable) Released 2020-04-07 - The new SameSite behaviour has been the default
Firefox 79 (stable) Released: 2020-07-28 - Rolled it out to 50% of users

Mozilla is cooperating with Google to track and share reports of website breakage in our respective bug tracking databases.

Backwards Compatibility

Google Chrome

Chrome version 4 to 50 doesn't supports. Chrome version 51 to 60 partially supports it. Chrome 61 to 70 supports SECURITY 'SameSite' cookie attribute.

Mozilla Firefox

Firefox version 2 to 59 doesn't supports. Firefox version 60 to 63 supports SECURITY 'SameSite' cookie attribute.

Internet Explorer

IE browser version 6 and 10 doesn't supports. IE browser version 11 partially supports SECURITY 'SameSite' cookie attribute.

Safari

Safari browser version 3.1 to 11.1 doesn't supports. Safari browser version 12 supports SECURITY 'SameSite' cookie attribute.

Microsoft Edge

Microsoft Edge browser version 12 to 15 doesn't supports. Microsoft Edge browser version 16 to 18 supports SECURITY 'SameSite' cookie attribute property.

Opera

Opera version 10.1 to 38 doesn't supports. Opera version 39 to 53 supports SECURITY 'SameSite' cookie attribute.

Known Bugs

Safari

See: Cookies with SameSite=None or SameSite=invalid treated as Strict

nathan-van-der-werf · 2020-10-01T12:26:04Z

I disagree on setting the default value to "Strict", in my opinion the default should be "Lax" (like the default of Chrome (also providing backwards compatibility)).

When clicking a link to your website it will "provide a new cookie" when the setting is "Strict", therefore you will be logged out from your website, not very convenient for 99% of the websites.

If people need the extra security they can make it "Strict". The only time I've seen the SameSite on Strict was when I logged into my bank.

Even GitHub has the user session cookie "Lax" (along with a strict cookie with the same value).

summercms · 2020-10-01T14:45:20Z

The strict value will prevent the cookie from being sent by the browser to the target site in all cross-site browsing context, even when following a regular link. For example, for a GitHub-like website this would mean that if a logged-in user follows a link to a private GitHub project posted on a corporate discussion forum or email, GitHub will not receive the session cookie and the user will not be able to access the project.

p.s. I let the admins decide, just expanding your comment with some extra info. 👍

nathan-van-der-werf · 2020-10-01T16:37:50Z

The strict value will prevent the cookie from being sent by the browser to the target site in all cross-site browsing context, even when following a regular link. For example, for a GitHub-like website this would mean that if a logged-in user follows a link to a private GitHub project posted on a corporate discussion forum or email, GitHub will not receive the session cookie and the user will not be able to access the project.

I know how SameSite works.

Following your editted comment:

So why are you never logged out of github when they have this
Because of the non-strict, but lax user_session cookie, it's a different implementation by GitHub which we don't have in OctoberCMS.

The "__Host-user_session_same_site" won't be sent as a cookie when you enter GitHub from for example Google (that's how strict works); but because they got the user_session cookie (lax) it makes sure you'll stay logged in. Since OctoberCMS doesn't have this implementation it won't be a good idea to make "Strict" as a default value.

Cookies when you enter GitHub from a different origin:

summercms · 2020-10-01T17:51:41Z

I know how SameSite works.

I expanded your comment for other people and admins to read.

LukeTowers · 2020-10-01T19:58:44Z

I'm in agreement with @nathan-van-der-werf regarding the default policy value being "Lax". I thought the cross origin request rules would have only applied to POST requests, not GET requests triggered by clicking on a link to the site. For the vast majority of October CMS sites, Lax is perfectly acceptable and the expected behaviour. Developers that need "Strict" can still make that decision for themselves.

As a side note, with Strict wouldn't that mean if I click on octobercms.com from Google with Strict then I won't be logged in, but if I then just reload the page I would be? That seems stupid to me.

bennothommo · 2020-10-01T23:44:56Z

@LukeTowers

As a side note, with Strict wouldn't that mean if I click on octobercms.com from Google with Strict then I won't be logged in, but if I then just reload the page I would be? That seems stupid to me.

I'm pretty sure that's exactly what happens. It makes sense for sites where you should log in every time (like a banking site as @nathan-van-der-werf exampled), but it definitely shouldn't be the norm.

nathan-van-der-werf · 2020-10-02T07:14:45Z

@LukeTowers

I thought the cross origin request rules would have only applied to POST requests, not GET requests triggered by clicking on a link to the site.

In the case of Lax the cookies will be sent with GET requests only, with Strict it will never be sent (in the context of a cross origin request).

As a side note, with Strict wouldn't that mean if I click on octobercms.com from Google with Strict then I won't be logged in, but if I then just reload the page I would be? That seems stupid to me.

When you reload you'll still be logged out, the session cookie is not sent with the first request so the application / website "doesn't know you" and will give you a new session cookie.

LukeTowers · 2020-10-02T08:25:40Z

@nathan-van-der-werf wouldn't that be even worse since then simply clicking on a link to bank.com while logged into bank.com on another tab would log you out of bank.com on the first tab?

When you reload you'll still be logged out, the session cookie is not sent with the first request so the application / website "doesn't know you" and will give you a new session cookie.

nathan-van-der-werf · 2020-10-02T08:36:34Z

@nathan-van-der-werf wouldn't that be even worse since then simply clicking on a link to bank.com while logged into bank.com on another tab would log you out of bank.com on the first tab?

When you reload you'll still be logged out, the session cookie is not sent with the first request so the application / website "doesn't know you" and will give you a new session cookie.

Correct, for banking (or government) applications it's a great feature since it provides maximum security. But for the average website or web application it provides a horrible user experience. That's why we shouldn't be using "Strict" as a default value but "Lax".

LukeTowers · 2020-10-02T08:41:40Z

@ayumi-cloud where in the codebase is the default set (i.e. when polling Config::get(session.same_site, default))?

summercms · 2020-10-02T11:52:13Z

@LukeTowers

where in the codebase is the default set (i.e. when polling Config::get(session.same_site, default))?

Done, added it into the file: https://github.com/octobercms/october/blob/develop/modules/cms/classes/Controller.php

(Same place you and bennothommo did your previous pr's).

p.s. Let me know any issues with the description or not? I'm off to get a coffee now.

modules/cms/classes/Controller.php

summercms · 2020-10-02T14:42:25Z

Thanks for all the feedbacks.

LukeTowers · 2020-10-02T17:51:17Z

Done, added it into the file: https://github.com/octobercms/october/blob/develop/modules/cms/classes/Controller.php

That's not what I meant, sorry. I meant where in the current codebase calls Config::get('session.same_site') and what does it use as the default value at that point?

summercms · 2020-10-02T20:51:40Z

I thought October uses the Symfony package to deal with it, see here: https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpFoundation/Cookie.php

[edit] sorry not totally understanding what you are asking, maybe someone want to jump in and answer.

LukeTowers · 2020-10-03T19:59:50Z

@ayumi-cloud what happens in modern browsers when same-site is set to null?

summercms · 2020-10-03T20:10:40Z

@LukeTowers

Chrome, Microsoft Edge and Firefox set the cookie internally to Lax, please read this old article for more info: https://stephenreescarter.net/csrf-is-dead-long-live-samesite-lax/

I'm not sure what Safari does?

https://groups.google.com/g/mozilla.dev.platform/c/nx2uP0CzA9k/m/BNVPWDHsAQAJ?pli=1

https://docs.microsoft.com/en-us/microsoft-edge/web-platform/site-impacting-changes

https://bugzilla.mozilla.org/show_bug.cgi?id=1551798

Also as per the spec:

First, cookies should be treated as
"SameSite=Lax" by default. Second, cookies that explicitly assert
"SameSite=None" in order to enable cross-site delivery should also be
marked as "Secure". Third, same-site should take the scheme of the
sites into account. Fourth, cookies should respect schemes. Fifth,
cookies associated with non-secure schemes should be removed at the
end of a user's session. Sixth, the definition of a session should
be tightened.

Link: https://tools.ietf.org/html/draft-west-cookie-incrementalism-01

summercms · 2020-10-03T20:47:44Z

I was just thinking, it useful this pr sets the default to Lax and not null because I know IE11 does a different method of using SameSite and so I'm not sure it can handle a null, so it's good this pr sets the default to Lax

p.s. don't quote me on this with IE11 not 100% sure though.

config/session.php

summercms · 2020-10-07T11:05:25Z

Moved all useful information to the top comment. Hopefully then answers anyone's questions in the future. I consider this pr done now and leave the testers to just confirm everything is working and ok.

modules/cms/classes/Controller.php

…o samesite

LukeTowers · 2020-10-10T20:04:45Z

@bennothommo @nathan-van-der-werf any final comments?

nathan-van-der-werf · 2020-10-11T12:13:34Z

@bennothommo @nathan-van-der-werf any final comments?

Haven't tested it, but it looks good like this.

modules/system/ServiceProvider.php

SameSiet Cookie

531a5dc

summercms mentioned this pull request Oct 1, 2020

Use browser 2020 recommendations for SameSite cookie rules #4881

Closed

Remove whitespace as per Travis request

22f7435

LukeTowers added Status: Revision Needed Type: Maintenance labels Oct 2, 2020

Ayumi Hamasaki added 3 commits October 2, 2020 12:30

set default + lax

4d684ba

correction - my bad

c057715

indents issue

450f26f

nathan-van-der-werf reviewed Oct 2, 2020

View reviewed changes

modules/cms/classes/Controller.php Outdated Show resolved Hide resolved

credit to @Samuell1 suggestion

95b7ba9

bennothommo added Testing Needed and removed Status: Revision Needed labels Oct 7, 2020

bennothommo reviewed Oct 7, 2020

View reviewed changes

config/session.php Outdated Show resolved Hide resolved

config/session.php Show resolved Hide resolved

Update session.php

f6e0418

LukeTowers reviewed Oct 8, 2020

View reviewed changes

modules/cms/classes/Controller.php Outdated Show resolved Hide resolved

Update modules/cms/classes/Controller.php

5a53968

LukeTowers reviewed Oct 8, 2020

View reviewed changes

modules/cms/classes/Controller.php Outdated Show resolved Hide resolved

Ayumi Hamasaki added 4 commits October 9, 2020 08:20

need a rebase

0931104

Merge branch 'samesite' of https://github.com/ayumi-cloud/october int…

2800a22

…o samesite

Merge remote-tracking branch 'upstream/develop' into samesite

af1eebc

Update ServiceProvider.php

7c56ef9

LukeTowers added this to the v1.1.1 milestone Oct 10, 2020

LukeTowers reviewed Oct 12, 2020

View reviewed changes

modules/system/ServiceProvider.php Show resolved Hide resolved

LukeTowers added Status: Completed and removed Testing Needed labels Oct 12, 2020

LukeTowers merged commit df4c2cf into octobercms:develop Oct 12, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use browser 2020 recommendations for SameSite cookie rules #5293

Use browser 2020 recommendations for SameSite cookie rules #5293

summercms commented Oct 1, 2020 •

edited

Loading

nathan-van-der-werf commented Oct 1, 2020 •

edited

Loading

summercms commented Oct 1, 2020 •

edited

Loading

nathan-van-der-werf commented Oct 1, 2020 •

edited

Loading

summercms commented Oct 1, 2020 •

edited

Loading

LukeTowers commented Oct 1, 2020

bennothommo commented Oct 1, 2020

nathan-van-der-werf commented Oct 2, 2020 •

edited

Loading

LukeTowers commented Oct 2, 2020

nathan-van-der-werf commented Oct 2, 2020

LukeTowers commented Oct 2, 2020

summercms commented Oct 2, 2020 •

edited

Loading

summercms commented Oct 2, 2020

LukeTowers commented Oct 2, 2020

summercms commented Oct 2, 2020 •

edited

Loading

LukeTowers commented Oct 3, 2020

summercms commented Oct 3, 2020 •

edited

Loading

summercms commented Oct 3, 2020

summercms commented Oct 7, 2020

LukeTowers commented Oct 10, 2020

nathan-van-der-werf commented Oct 11, 2020

Use browser 2020 recommendations for SameSite cookie rules #5293

Use browser 2020 recommendations for SameSite cookie rules #5293

Conversation

summercms commented Oct 1, 2020 • edited Loading

Question 1

Answer 1

Question 2

Answer 2

Question 3

Answer 3

Question 4

Answer 4

Question 5

Answer 5

Testing

Google Chrome Cookie Legacy SameSite Policies

The SameSite attribute

Schemeful Same-Site

Legacy SameSite behavior

Configuring LegacySameSiteCookieBehaviorEnabledForDomainList

Browser Timeline Notes

Backwards Compatibility

Google Chrome

Mozilla Firefox

Internet Explorer

Safari

Microsoft Edge

Opera

Known Bugs

Safari

nathan-van-der-werf commented Oct 1, 2020 • edited Loading

summercms commented Oct 1, 2020 • edited Loading

nathan-van-der-werf commented Oct 1, 2020 • edited Loading

summercms commented Oct 1, 2020 • edited Loading

LukeTowers commented Oct 1, 2020

bennothommo commented Oct 1, 2020

nathan-van-der-werf commented Oct 2, 2020 • edited Loading

LukeTowers commented Oct 2, 2020

nathan-van-der-werf commented Oct 2, 2020

LukeTowers commented Oct 2, 2020

summercms commented Oct 2, 2020 • edited Loading

summercms commented Oct 2, 2020

LukeTowers commented Oct 2, 2020

summercms commented Oct 2, 2020 • edited Loading

LukeTowers commented Oct 3, 2020

summercms commented Oct 3, 2020 • edited Loading

summercms commented Oct 3, 2020

summercms commented Oct 7, 2020

LukeTowers commented Oct 10, 2020

nathan-van-der-werf commented Oct 11, 2020

summercms commented Oct 1, 2020 •

edited

Loading

`Google Chrome` Cookie Legacy SameSite Policies

nathan-van-der-werf commented Oct 1, 2020 •

edited

Loading

summercms commented Oct 1, 2020 •

edited

Loading

nathan-van-der-werf commented Oct 1, 2020 •

edited

Loading

summercms commented Oct 1, 2020 •

edited

Loading

nathan-van-der-werf commented Oct 2, 2020 •

edited

Loading

summercms commented Oct 2, 2020 •

edited

Loading

summercms commented Oct 2, 2020 •

edited

Loading

summercms commented Oct 3, 2020 •

edited

Loading