Magento2: SameSite cookie, posible issues

[diazwatson]

Preconditions (*)

On February, 4, Google is set to roll out a new Chrome update that promises a bunch of new features designed to make the browser faster and more secure — including a new approach to cookies.

The SameSite update will require website owners to explicitly state label the third-party cookies that can be used on other sites. Cookies without the proper labelling won’t work in the Chrome browser, which has 63.62% of the overall browser market, according to Statcounter.

Right now, the Chrome SameSite cookie default is: “None,” which allows third-party cookies to track users across sites. But from February, cookies will default into “SameSite=Lax,” which means cookies are only set when the domain in the URL of the browser matches the domain of the cookie — a first-party cookie.

This will not probably affect Magento itself but what about it 3rd party integrations which comes pre installed by default such as NewRelic?

Steps to reproduce (*)

1. Open Chrome and go to chrome://flags/
2. Enable SameSite by default cookies and Cookies without SameSite must be secure
3. Open the Chrome inspector.

Expected result (*)

1. No errors or warnings should show.

Actual result (*)

Production site

Admin Panel of a Vanilla Magento 2.3-develop site

Paying with PayPal Express sandbox account

Related links

• https://www.chromestatus.com/feature/5088147346030592
• https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/
• https://tools.ietf.org/html/draft-west-first-party-cookies-07
• https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/
• https://medium.com/adobetech/adobe-experience-cloud-cookie-updates-for-google-chrome-19ad67cf1598
• https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/
• https://blog.chromium.org/2019/10/developers-get-ready-for-new.html
• https://help.salesforce.com/articleView?id=000351874&language=en_US&type=1&mode=1

[m2-assistant[bot]]

Hi @diazwatson. Thank you for your report.
To help us process this issue please make sure that you provided the following information:

• [x] Summary of the issue
• [x] Information on your environment
• [x] Steps to reproduce
• [x] Expected and actual results

Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:

@magento give me 2.4-develop instance - upcoming 2.4.x release

For more details, please, review the Magento Contributor Assistant documentation.

@diazwatson do you confirm that you were able to reproduce the issue on vanilla Magento instance following steps to reproduce?

• [x] yes
• [ ] no

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

[okorshenko]

@magento give me 2.4-develop instance

[magento-engcom-team]

Hi @okorshenko. Thank you for your request. I'm working on Magento 2.4-develop instance for you

[magento-engcom-team]

Hi @okorshenko, here is your Magento instance.
Admin access: https://i-26377-2-4-develop.instances.magento-community.engineering/admin
Login: admin Password: 123123q
Instance will be terminated in up to 3 hours.

[devchris79]

I think this is a possible duplicate of #26310

[diazwatson]

It is indeed @devchris79 thanks for linking both issues 👍

[m2-assistant[bot]]

Hi @engcom-Charlie. Thank you for working on this issue.
In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:

• [ ] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
  Details

  If the issue has a valid description, the label Issue: Format is valid will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid appears.

• [ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description label to the issue by yourself.

• [ ] 3. Add Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

• [ ] 4. Verify that the issue is reproducible on 2.4-develop branch

  Details

  - Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and _stop verification process here_!

• [ ] 5. Add label Issue: Confirmed once verification is complete.

• [ ] 6. Make sure that automatic system confirms that report has been added to the backlog.

[magento-engcom-team]

:white_check_mark: Confirmed by @engcom-Charlie
Thank you for verifying the issue. Based on the provided information internal tickets MC-30452 were created

Issue Available: @engcom-Charlie, _You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself._

[diazwatson]

@engcom-Charlie thanks for reviewing and testing this issue.
Can I request one of the architects from the security team to provide some guidance on what would be the best approach to fix this issue?

[DavaGordon]

Issues come across as a result of sameSite in the last 24 hours are if you do not have an active backend SSL certificate then both Chrome & Firefox will not allow you to log in to the backend admin panel rather it will simply refresh without any errors and warning.

After looking further into it I think the cause of this is down to a commit made 22 days ago https://github.com/zendframework/zend-http/commit/84d4615bba86474dc5ee4014040a417fb91c3b3d

Steps to Reproduce

• Install Magento 2.3.3
• Navigate to Admin
• Try and Login

Result
The page refreshes as the admin area is not set to secure and you are unable to login,

Temporary workaround until permanent fix found
Once you enable secure in adminhtml in the either in the database core_config_data table or by running bin/magento config:set web/secure/use_in_adminhtml 1 and cleaning the cache you will then gain admin access to the website again.

[diazwatson]

@okorshenko @magento-engcom-team guys do you see any potential issue in production sites with this change going live next week?

[dyushkin]

Hello @diazwatson!
I have created an internal Magento ticket MC-31046. The fix should be completed and delivered into the 2.4-develop branch with internal PR.
Thank you for your collaboration.

[DavaGordon]

Hello @diazwatson!
I have created an internal Magento ticket MC-31046. The fix should be completed and delivered into the 2.4-develop branch with internal PR.
Thank you for your collaboration.

This comes in tomorrow so a fix is a pretty high priority as it will affect a lot of payment gateways thus making the checkout process impossible

[TonyMerlin]

Any news on this as yet as we've got cookies failing to load from multiple sources now on 2.3.4

[sjb9774]

It appears this new behavior breaks Payflow Pro credit card processing: https://github.com/magento/magento2/issues/26840

[sjb9774]

Also valuable to note per https://www.chromium.org/updates/same-site this SameSite functionality will not become the default behavior even on Chrome 80 until the 17th (and even then it seems it will be limited in scope).

[diazwatson]

I guess it is due to all the issue it cause. But it will be done sooner or later so better to be prepared.

[sjb9774]

@dyushkin Do you have any insight into the related task https://github.com/magento/magento2/issues/26840? It seems like a pretty serious issue

[HirokazuNishi]

Guys, I published quick & dirty fix module for this issue.

https://github.com/Veriteworks/CookieFix

We tested it against 3DS payment and worked fine.

[asim-vax]

Has there been any progress made? We are seeing this affect customers now

[sjb9774]

@asim-vax In what way?

[asim-vax]

@sjb9774 our 3DS payment gateways were redirecting to blank basket after inputting their bank details (session cookie not persisting). The fix from @HirokazuNishi (thank you!)worked great, and has fixed it for us(setting samesite to none, and secure to true)

[devchris79]

The fix module from @HirokazuNishi doesn't appear to correct the cookies from the Google ReCaptcha functionality in the core:

[HirokazuNishi]

@devchris79 seems these cookies are sent from google. Not from your M2 instance.
But... please submit such report to our repo. Not here.

[othuress]

Being an end-user of the system this is issue is a mega catastrophe I can not stress enough that this GAP needs to be fixed in Magento, we are loosing sales due to extent of void payments from Chrome browsers!

"Same site cookie policy issue in Magento2 Since the SameSite Cookie Changes redirect payment method flows can break when the issuer is redirecting back to the Magento site with a POST request. When Magento processes the POST request it starts with loading the cart from the session. In order to do so it reaches to the SESSION cookie. Unfortunately the SESSION cookie is not set as SameSite=None; Secure therefore the browser is going to decline using the cookie so the process fails and Magento redirects back to the empty cart page. Since the redirect is not handled by Magento the payment is not finalised and the order stays as new.

To solve this issue the SESSION cookie should be set as SameSite=None; Secure so POST requests from outside of the Magento website domain can also be processed."

[OlegsJakovlevsJp]

“Same site cookie policy issue in Magento2 Since the SameSite Cookie Changes redirect payment method flows can break when the issuer is redirecting back to the Magento site with a POST request. When Magento processes the POST request it starts with loading the cart from the session. In order to do so it reaches to the SESSION cookie. Unfortunately, the SESSION cookie is not set as SameSite=None; Secure therefore the browser is going to decline using the cookie so the process fails and Magento redirects back to the empty cart page. Since the redirect is not handled by Magento the payment is not finalized and the order stays as new.

To solve this issue the SESSION cookie should be set as SameSite=None; Secure so POST requests from outside of the Magento website domain can also be processed.“

[adarshkhatri]

So what's the solution to this?

[theramppeople]

This is preventing 3d secure and causing us major issues!

[okorshenko]

Hi All! We are doing our best to have it fixed in 2.4.1. Internal Epic has several stories and these stories are In Dev right now.

[ldubreuil]

@okorshenko any update on this?

[kzobov]

@okorshenko
can this be pushed in 2.3.5-p3 or as a hotfix?
This is causing a lot of issues and upgrade from 2.3.5 to 2.4 is another full update which will consume resources

[manezaf8]

How far is Magento from fixing this issue ?

[devchris79]

@okorshenko
can this be pushed in 2.3.5-p3 or as a hotfix?
This is causing a lot of issues and upgrade from 2.3.5 to 2.4 is another full update which will consume resources

This should most definitely be added to 2.3. Magento 2.4 requires Elasticsearch that is built on Java and many hosted services including ours (Siteground) don't support it.

[smiverma]

Magento 2.3 still supports PHP 7.2 and PHP 7.2 doesn't support SameSite attribute for secookies() function so we cannot add explicit support for SameSite in Magento framework. we are investigating what could be done on our side to support 2.3 line however we have added support in our next release 2.4.1

[hardyjohnson]

There are multiple examples of setcookie polyfills for lower PHP versions, one of which is provided by GoogleChromeLabs (https://github.com/GoogleChromeLabs/samesite-examples/blob/master/php.md) and a similar one from @HirokazuNishi (https://github.com/Veriteworks/CookieFix) mentioned above. While those solutions may not be elegant, they surely can be implemented in the framework to uphold any interface contracts expected in the Magento Framework.

We have production sites which are freezing during the payment redirect flow and upgrade to 2.4.x will not be in the cards prior to this holiday season. A fix in the next patch release for 2.3.x is critical for our clients.

Thank you for working on open source software. We will look and post any solutions we come up with in the meantime. We are running on 2.3.5-p1, but should be on p2 soon and PHP7.2 transitioning to 7.3 soon, so will need to support both sides of the application and platform fixes.

[ktsour]

Guys, I published quick & dirty fix module for this issue.

https://github.com/Veriteworks/CookieFix

We tested it against 3DS payment and worked fine.

I have tried your plugin but it makes the add-to-cart to stop working. I will post an issue to your repo too.

My workaround was to add the following in the .htaccess file:
Header always edit Set-Cookie ^(PHPSESSID.*)$ $1;HttpOnly;Secure;SameSite=None

I hope it helps until a permanent solution is found.

[Blatant]

Another angle, I'm currently using this stanza in my .htaccess file. Prob best to fix within the framework tho.

    <If "%{HTTP_USER_AGENT} !~ /(iPhone; CPU iPhone OS 1[0-2]|iPad; CPU OS 1[0-2]|iPod touch; CPU iPhone OS 1[0-2]|Macintosh; Intel Mac OS X.*Version\x2F1[0-2].*Safari|Macintosh;.*Mac OS X 10_14.* AppleWebKit.*Version\x2F1[0-3].*Safari)/i">
        Header always edit Set-Cookie (.*) "$1; SameSite=None; Secure"
    </If>

It excludes the browsers where the implementation is a bit bawked ATM (Safari sic). But this might help someone panicking with a live site as a quick fix. Seems to be working out ok on our prod servers.

Its not my work, but based on one of a number of topics on webmaster.stackexchange.com

Source : https://webmasters.stackexchange.com/questions/128635/chrome-80-clears-session-cookies-for-users-returning-from-payment-gateway

Edit : Extends a bit on @ktsour response above 👍

[vpodorozh]

@okorshenko - so 2.4.1 is expected version with a fix?
thx!

[johnorourke]

@ktsour @Blatant if you're struggling because PHPSESSID gets set without it my PR might help: https://github.com/magento/magento2/issues/27531 - I haven't had time to make the unit tests they asked for so it got closed.

[Blatant]

Thanks @johnorourke I had seen this already, however I didn't want to add yet another module and overhead to the thing and (a true SysAdmin here) I preferred the elegance of a htaccess/vhost apache born solution. IMHO it just seems more elegant and concise to tackle it at the Apache level with a one shot stanza, and time was of the essence.

I do agree your module seems to sort it however I will wait for Adobe to tackle this in the core. Not to dissuade anyone from looking at your module of course!

[TonyMerlin]

Another angle, I'm currently using this stanza in my .htaccess file. Prob best to fix within the framework tho.

    <If "%{HTTP_USER_AGENT} !~ /(iPhone; CPU iPhone OS 1[0-2]|iPad; CPU OS 1[0-2]|iPod touch; CPU iPhone OS 1[0-2]|Macintosh; Intel Mac OS X.*Version\x2F1[0-2].*Safari|Macintosh;.*Mac OS X 10_14.* AppleWebKit.*Version\x2F1[0-3].*Safari)/i">
        Header always edit Set-Cookie (.*) "$1; SameSite=None; Secure"
    </If>

It excludes the browsers where the implementation is a bit bawked ATM (Safari sic). But this might help someone panicking with a live site as a quick fix. Seems to be working out ok on our prod servers.

Its not my work, but based on one of a number of topics on webmaster.stackexchange.com

Source : https://webmasters.stackexchange.com/questions/128635/chrome-80-clears-session-cookies-for-users-returning-from-payment-gateway

Edit : Extends a bit on @ktsour response above 👍

How can this be implemented in Nginx?

[diazwatson]

Some very interesting & fun ways to debug and prove sameSite cookie issues (for chrome browsers).
https://www.chromium.org/updates/same-site/test-debug

[elvinristi]

Related Safari on MacOS 10.14, ipad/iphone bug when forcing SameSite=None

• https://bugs.webkit.org/show_bug.cgi?id=198181
• https://www.chromium.org/updates/same-site/incompatible-clients

I have done vice versa - patched on app level to send always SameSite=None and in Apache 2.4 level removing for those specific OS/browsers

# https://bugs.webkit.org/show_bug.cgi?id=198181
<If "%{HTTP_USER_AGENT} =~ /(iPhone; CPU iPhone OS 1[0-3]|iPad; CPU OS 1[0-3]|iPod touch; CPU iPhone OS 1[0-3]|Macintosh; Intel Mac OS X.*Version\x2F1[0-3].*Safari|Macintosh;.*Mac OS X 10_14.* AppleWebKit.*Version\x2F1[0-3].*Safari|(Chrom[^ \x2F]+\x2F(([5][1-9])|([6][0-7]))[\.\d]*[ ]))/i">
  Header always edit Set-Cookie "^(.*)(;[ ]?SameSite=None|;[ ]?samesite=None)(.*)?$" "$1$3"
</If>

[tuyennn]

What is the current status of this major issue? The promise for the fix is about 9 months ago

[hostep]

@tuyennn: It looks like it's coming in Magento 2.4.1 (15 October) according to the bèta release notes:

Magento Open Source 2.4.1 introduces enhancements to performance and security. Security enhancements include support for the SameSite attribute for cookies and the addition of CAPTCHA protection for payment-related and order-related API endpoints and the Place Order storefront page.
...
Support for the SameSite attribute for cookies. To support the Google Chrome enforcement of the new cookie classification system, Magento classes that handle cookies have been updated to support the SameSite cookie attribute. This attribute is set to Lax by default but can be explicitly overridden.

Unfortunately no mentioning on the 2.3.6 bèta release notes, which is very disappointing 👎

[tuyennn]

@hostep Thank you for your information, great to know that. Were those related commits appeared on the 2.4-develop branch?

[hostep]

@tuyenn: according the "hidden" information in the release notes, these are done under ticket MC-35389:

But I can't find any commits yet on the 2.4-develop branch which mention that ticket. So I assume they'll only publish these when 2.4.1 is released, which is strange ...

[nathanjosiah]

Due to our release cycles and code freeze dates these changes had no choice but to go to 2.4.1. I just checked the mentioned internal ticket MC-35389 (and several other directly related tickets) and the commits were delivered to our internal private branches so unfortunately it looks like they will not be available until the public release.

As for 2.3.x I do not have an ETA right now but we are working on it.

[hardyjohnson]

@nathanjosiah thanks for the update, any chance this could be released through the Magento Quality patches channel for 2.3.x?

[JesKingDev]

Related Safari on MacOS 10.14, ipad/iphone bug when forcing SameSite=None

• https://bugs.webkit.org/show_bug.cgi?id=198181
• https://www.chromium.org/updates/same-site/incompatible-clients

I have done vice versa - patched on app level to send always SameSite=None and in Apache 2.4 level removing for those specific OS/browsers

@elvinristi Does your solution resolve the issue for Safari browsers? If, so, would you mind sharing a Gist of how you've solved this with patching at the app level? This is an incredibly impactful issue for us and we don't currently have a workaround for Safari. FYI @gowthamleanswift.

[elvinristi]

@JesKingDev,

This is the patch I use currently on Magento 2.4.1-beta2

• https://gist.github.com/elvinristi/a3263ca92a62ff68a838650dd0e91667

And this is used on Apache 2.4 vhost conf

• https://gist.github.com/elvinristi/87674507e854524b12bf2fa286a98f2d

This solved for me Safari running on macOs Mojave (v 10.14)

[yogeshkarodiya]

Is there any patch available for Magento2.3? or any hard fix for this issue because above solutions are not working