SameSite cookie, posible issues

[diazwatson]

| QPT Data Collection|borderStyle=dashed|borderColor=#cccccc|titleBGColor=#dddddd|bgColor=#e3ffea |
| --- |
|

• QPT release:
  1.0.20
• Patch ID
  MC-41359
• Are there any additional actions required after the patch installation to make it work?
  N/A
• Compatible with Magento versions:
  Check compatibility
  |

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]

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

• Summary of the issue
• Information on your environment
• Steps to reproduce
• 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?

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

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: 👇

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

✅ 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 zendframework/zend-http@84d4615

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: #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 #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

[live4soccer7]

The issue is samesite cookie "LAX" when it should be set to NONE. This is likely because it is not getting set at all in magento and chrome is setting the cookie to lax by default.

[salehawal]

The issue is samesite cookie "LAX" when it should be set to NONE. This is likely because it is not getting set at all in magento and chrome is setting the cookie to lax by default.

lax works fine, but if you check the cookies in the browsers some of them who have "none" without the secure tag are causing the problem, the solution is simple just add the "secure" tag but the problem is a magento related "which file to edit?'

[live4soccer7]

My issue is LAX, but they are set to secure. This really only should effect cross-site communication abilities in a chrome based browser, which is payflow. My customers can not checkout using a credit card if they are on a chrome based browser. This is after the latest update of 2.4.3-p1.

Has anyone actually tested the fix on a production site with payflow?

[live4soccer7]

@salehawal Do you have cookie restriction mode enabled? I do not and I am wondering if maybe that needs to be enabled for the cookies to have the proper attributes assigned.

[salehawal]

@live4soccer7 frankly i don't know, but still working on how to resolve this, or lets say find the responsible file to edit it.

[live4soccer7]

@salehawal You can sign into your admin and check. It is a setting in the backend under general --> web --> cookies. We have opposing problems, so perhaps it could have to do with the way we each have our settings. It shouldn't really matter, but could just be the way the fix is applied and isn't fully "idiot" proof with the settings in admin. When I get some time, I'll screenshot my related settings in admin for cookies and sessions. Comparing our settings may help, if you don't mind doing so.

[salehawal]

@live4soccer7 there you go
1- admin | cookie config
2- browser cookie storage
3- browser console view ( errors )

[live4soccer7]

Here are my current settings

.

[live4soccer7]

[salehawal]

@diazwatson

[diazwatson]

@salehawal @live4soccer7
Do you guys have @ihor-sviziev changes applied in your local instance?

[live4soccer7]

@diazwatson
I have not applied anything outside the stock magento install. Is there something that needs applied to get this to work properly on 2.4.3-p1?

[live4soccer7]

My store was migrated from an M1 installation, is there anything to check for in the DB that could be affecting this?

[diazwatson]

Don't think the DB but the source code.
Make sure your source code contains these changes:
https://github.com/magento/quality-patches/pull/47/files

[live4soccer7]

@diazwatson even though it states <2.4.2? It is not resolved in >2.4.2?

MC-41359 (for Magento >=2.3.6-p1 <2.3.7, >=2.4.2 <2.4.3)-Fixes the issue of the incorrect SameSite cookie parameters settings.

It does not show up in the quality patches when you run the command in CLI for 2.4.3-p1

edit: I have checked each change in the 2.4.2 patch and the files in 2.4.3-p1 all have these changes in my installation

[salehawal]

Don't think the DB but the source code. Make sure your source code contains these changes: https://github.com/magento/quality-patches/pull/47/files
@diazwatson
i pulled branch 2.4-develop, i made a fresh pull and merged with my dev branch, but still not resolved

i also followed your link: https://github.com/magento/quality-patches/pull/47/files
and tried to apply the patch : gh pr checkout 47

i get this error: GraphQL error: Could not resolve to a PullRequest with the number of 47.

[live4soccer7]

@salehawal if you're on the latest magento then the patch is already included, but there is still a problem with the cookies as shown by my screenshots.

What do you have for your varnish and session settings in the admin area of magento?

[salehawal]

@live4soccer7 i am focusing on the cookie issue now, varnish and session has no effect on this case i guess

[live4soccer7]

@salehawal it could have an effect, which is why it doesn't hurt to check such settings.

[ihor-sviziev]

@salehawal, the PR on magento2 repo was #32462

[salehawal]

@ihor-sviziev @diazwatson @live4soccer7
added as new issue : #34461

[chickyd3v]

We've found a workaround for the cookie issue, currently it works just fine in our 2 projects.
Basically the issue is the session being cleared whenever the browser is processing a POST request from 3rd party system to Magento instance (like, when redirecting from Payment Gateway to Magento after payment succeed). So we created a plugin of the SessionStartChecker class and exclude the callback URL that the 3rd party system is using to POST back the data to Magento.

app/code/SB/Framework/etc/di.xml:

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">
    <type name="Magento\Framework\Session\SessionStartChecker">
        <plugin name="CallbackSessionChecker"
                type="SB\Framework\Plugin\CallbackSessionChecker"/>
    </type>
</config>

app/code/SB/Framework/Plugin/CallbackSessionChecker.php:

namespace SB\Framework\Plugin;

use Magento\Framework\App\Request\Http;
use Magento\Framework\Session\SessionStartChecker;

class CallbackSessionChecker
{
    /**
     * Array
     */
    private const PAYMENT_CALLBACK_PATHS = [
        'payso/payment/response',
        'KbankOnlinePayment/Callback/Card',
        'KbankOnlinePayment/Callback/Qr',
        'p2c2p/payment/response',
        'P2c2p/payment/response',
        'sociallogin/social/callback'
    ];

    /**
     * @var Http
     */
    private $request;

    /**
     * @param Http $request
     */
    public function __construct(Http $request)
    {
        $this->request = $request;
    }
    /**
     * Check if session can be started or not, taking payment extension's response action into consideration
     * @param \Magento\Framework\Session\SessionStartChecker $subject
     * @param bool $result
     * @return bool
     */
    public function afterCheck(\Magento\Framework\Session\SessionStartChecker $subject, bool $result) : bool
    {
        if ($result === false) {
            return false;
        }

        $inArray = true;
        foreach (self::PAYMENT_CALLBACK_PATHS as $path) {
            if (strpos((string)$this->request->getPathInfo(), $path) !== false) {
                $inArray = false;
                break;
            }
        }
        return $inArray;
    }
}

Hope this can help someone.

[live4soccer7]

@chickyd3v This works for the payflow pro samesite cookie issue, ie the cookie not being set to None? Has it been tested/used on the latest magento 2.4.3-p1?

[ihor-sviziev]

Could you report this issue separately? Thank you!

…

On Thu, 28 Oct 2021 at 18:33 live4soccer7 ***@***.***> wrote: @chickyd3v <https://github.com/chickyd3v> This works for the payflow pro samesite cookie issue? Has it been tested/used on the latest magento 2.4.3-p1? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#26377 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOJOUNWGR6422PPVOAH3K3UJFUMDANCNFSM4KGILURQ> .

[live4soccer7]

@ihor-sviziev I have created a new issue here: #34472 Please let me know there if you need/want any additional information as gateway issues are tough to track down and sandbox vs production seems to be different results.

[wajihkm]

We've found a workaround for the cookie issue, currently it works just fine in our 2 projects. Basically the issue is the session being cleared whenever the browser is processing a POST request from 3rd party system to Magento instance (like, when redirecting from Payment Gateway to Magento after payment succeed). So we created a plugin of the SessionStartChecker class and exclude the callback URL that the 3rd party system is using to POST back the data to Magento.

app/code/SB/Framework/etc/di.xml:

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">
    <type name="Magento\Framework\Session\SessionStartChecker">
        <plugin name="CallbackSessionChecker"
                type="SB\Framework\Plugin\CallbackSessionChecker"/>
    </type>
</config>

app/code/SB/Framework/Plugin/CallbackSessionChecker.php:

namespace SB\Framework\Plugin;

use Magento\Framework\App\Request\Http;
use Magento\Framework\Session\SessionStartChecker;

class CallbackSessionChecker
{
    /**
     * Array
     */
    private const PAYMENT_CALLBACK_PATHS = [
        'payso/payment/response',
        'KbankOnlinePayment/Callback/Card',
        'KbankOnlinePayment/Callback/Qr',
        'p2c2p/payment/response',
        'P2c2p/payment/response',
        'sociallogin/social/callback'
    ];

    /**
     * @var Http
     */
    private $request;

    /**
     * @param Http $request
     */
    public function __construct(Http $request)
    {
        $this->request = $request;
    }
    /**
     * Check if session can be started or not, taking payment extension's response action into consideration
     * @param \Magento\Framework\Session\SessionStartChecker $subject
     * @param bool $result
     * @return bool
     */
    public function afterCheck(\Magento\Framework\Session\SessionStartChecker $subject, bool $result) : bool
    {
        if ($result === false) {
            return false;
        }

        $inArray = true;
        foreach (self::PAYMENT_CALLBACK_PATHS as $path) {
            if (strpos((string)$this->request->getPathInfo(), $path) !== false) {
                $inArray = false;
                break;
            }
        }
        return $inArray;
    }
}

Hope this can help someone.

This solution has some issues with Guest customers.