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

SameSite cookie, posible issues #26377

Closed
diazwatson opened this issue Jan 13, 2020 · 110 comments · Fixed by #32462
Closed

SameSite cookie, posible issues #26377

diazwatson opened this issue Jan 13, 2020 · 110 comments · Fixed by #32462
Assignees
Labels
CD Issue recommended for the contribution day Component: Security Fixed in 2.4.x The issue has been fixed in 2.4-develop branch Issue: Clear Description Gate 2 Passed. Manual verification of the issue description passed Issue: Confirmed Gate 3 Passed. Manual verification of the issue completed. Issue is confirmed Issue: Format is valid Gate 1 Passed. Automatic verification of issue format passed Issue: Ready for Work Gate 4. Acknowledged. Issue is added to backlog and ready for development Priority: P1 Once P0 defects have been fixed, a defect having this priority is the next candidate for fixing. Progress: done Reported on 2.3.x Indicates original Magento version for the Issue report. Reproduced on 2.4.x The issue has been reproduced on latest 2.4-develop branch Severity: S1 Affects critical data or functionality and forces users to employ a workaround.

Comments

@diazwatson
Copy link
Contributor

diazwatson commented Jan 13, 2020

| 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
Screenshot 2020-01-13 at 20 21 44

Admin Panel of a Vanilla Magento 2.3-develop site
Screenshot 2020-01-13 at 20 35 08

Paying with PayPal Express sandbox account
Screenshot 2020-01-13 at 20 46 35

Related links

@m2-assistant
Copy link

m2-assistant bot commented Jan 13, 2020

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

@magento-engcom-team magento-engcom-team added the Issue: Format is valid Gate 1 Passed. Automatic verification of issue format passed label Jan 13, 2020
@okorshenko
Copy link
Contributor

@magento give me 2.4-develop instance

@magento-engcom-team
Copy link
Contributor

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

@magento-engcom-team
Copy link
Contributor

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
Copy link

I think this is a possible duplicate of #26310

@diazwatson
Copy link
Contributor Author

diazwatson commented Jan 14, 2020

It is indeed @devchris79 thanks for linking both issues 👍

@engcom-Charlie engcom-Charlie self-assigned this Jan 15, 2020
@m2-assistant
Copy link

m2-assistant bot commented Jan 15, 2020

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

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

@engcom-Charlie engcom-Charlie added Component: Security Issue: Clear Description Gate 2 Passed. Manual verification of the issue description passed Issue: Confirmed Gate 3 Passed. Manual verification of the issue completed. Issue is confirmed Reproduced on 2.4.x The issue has been reproduced on latest 2.4-develop branch labels Jan 15, 2020
@ghost ghost unassigned engcom-Charlie Jan 15, 2020
@magento-engcom-team magento-engcom-team added the Issue: Ready for Work Gate 4. Acknowledged. Issue is added to backlog and ready for development label Jan 15, 2020
@magento-engcom-team
Copy link
Contributor

✅ 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
Copy link
Contributor Author

@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
Copy link

DavaGordon commented Jan 21, 2020

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
Copy link
Contributor Author

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

@dyushkin
Copy link
Contributor

dyushkin commented Feb 3, 2020

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
Copy link

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
Copy link

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

@sjb9774
Copy link
Contributor

sjb9774 commented Feb 12, 2020

It appears this new behavior breaks Payflow Pro credit card processing: #26840

@sjb9774
Copy link
Contributor

sjb9774 commented Feb 12, 2020

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
Copy link
Contributor Author

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
Copy link
Contributor

sjb9774 commented Feb 12, 2020

@dyushkin Do you have any insight into the related task #26840? It seems like a pretty serious issue

@HirokazuNishi
Copy link
Contributor

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
Copy link
Contributor

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

@live4soccer7
Copy link

So it seems this problem isn't resolved and it's not just me going crazy over it.

@salehawal
Copy link

Error: Cookie “test” will be soon rejected because it has the “SameSite” attribute set to “None”

the solution seems simple, just we need to add "Secure" in the cookie config, but the challenge is "where" is the file location to edit?

@live4soccer7
Copy link

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
Copy link

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?'
Screenshot from 2021-10-24 17-22-47
Screenshot from 2021-10-24 17-22-31
Screenshot from 2021-10-24 17-22-20
Screenshot from 2021-10-24 17-21-50

@live4soccer7
Copy link

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
Copy link

@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
Copy link

@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
Copy link

live4soccer7 commented Oct 25, 2021

@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
Copy link

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

Screenshot from 2021-10-26 11-18-28
Screenshot from 2021-10-26 11-18-15
Screenshot from 2021-10-26 11-16-52

@live4soccer7
Copy link

Here are my current settings
Capture2
Capture1
Capture

.

@live4soccer7
Copy link

Capture

@salehawal
Copy link

Capture
@diazwatson

@diazwatson
Copy link
Contributor Author

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

@live4soccer7
Copy link

@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
Copy link

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

@diazwatson
Copy link
Contributor Author

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
Copy link

live4soccer7 commented Oct 27, 2021

@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
Copy link

salehawal commented Oct 27, 2021

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
Copy link

@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
Copy link

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

@live4soccer7
Copy link

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

@ihor-sviziev
Copy link
Contributor

@salehawal, the PR on magento2 repo was #32462

@salehawal
Copy link

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

@chickyd3v
Copy link

chickyd3v commented Oct 28, 2021

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
Copy link

live4soccer7 commented Oct 28, 2021

@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
Copy link
Contributor

ihor-sviziev commented Oct 28, 2021 via email

@live4soccer7
Copy link

@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
Copy link

wajihkm commented Jan 3, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CD Issue recommended for the contribution day Component: Security Fixed in 2.4.x The issue has been fixed in 2.4-develop branch Issue: Clear Description Gate 2 Passed. Manual verification of the issue description passed Issue: Confirmed Gate 3 Passed. Manual verification of the issue completed. Issue is confirmed Issue: Format is valid Gate 1 Passed. Automatic verification of issue format passed Issue: Ready for Work Gate 4. Acknowledged. Issue is added to backlog and ready for development Priority: P1 Once P0 defects have been fixed, a defect having this priority is the next candidate for fixing. Progress: done Reported on 2.3.x Indicates original Magento version for the Issue report. Reproduced on 2.4.x The issue has been reproduced on latest 2.4-develop branch Severity: S1 Affects critical data or functionality and forces users to employ a workaround.
Projects