Feature/Fix for SameSite Cookies, option to set to None during 5 minutes afte…

[OZZlE]

…r order placement so that services like 3d-Secure can post back to Magento, and Chrome+Magento is able to read the session cookies so an order is created.

Magento automatically reverts back to 'Lax' when you come back to the Success page (or any other page).

This is a major issue if you use Adyen for example with credit card iframes in the checkout.

See issue description here:

• https://github.com/GoogleChromeLabs/samesite-examples/blob/3d-secure-impl/3d-secure.md
• https://www.chromestatus.com/feature/5088147346030592
• https://web.dev/samesite-cookies-explained/

[colinmollenhour]

Thanks for the PR!

Does setting two cookies with identical parameters but different SameSite value cause one cookie to be overridden or two cookies? I'm guessing one cookie to be overridden because otherwise the server could only receive one value anyway due to conflicting key names. In that case this has an issue in that the cookie will either expire causing the user to be logged out, or the next cookie renew will just reset the SameSite status and it might not have accomplished it's goal yet.

I would advise leaving the frontend cookie alone and instead introducing a special cookie that is only recognized by the necessary endpoints. E.g. 'frontend_adyen' so when this special cookie is given and if it is validated (e.g. with an HMAC) then the correct session could be loaded.

[Flyingmana]

for the security point of view, is there any case where the session cookie should not be none?

[OZZlE]

Thanks for the PR!

NP!

Does setting two cookies with identical parameters but different SameSite value cause one cookie to be overridden or two cookies? I'm guessing one cookie to be overridden because otherwise the server could only receive one value anyway due to conflicting key names. In that case this has an issue in that the cookie will either expire causing the user to be logged out, or the next cookie renew will just reset the SameSite status and it might not have accomplished it's goal yet.

Yes setting a cookie with the same name as an already existing cookie overwrites it.

When magento renews the cookies when you come back it sets back the lifetime to whatever you have configured. In our case 12h.

I would advise leaving the frontend cookie alone and instead introducing a special cookie that is only recognized by the necessary endpoints. E.g. 'frontend_adyen' so when this special cookie is given and if it is validated (e.g. with an HMAC) then the correct session could be loaded.

The problem is that Magento stores the Session ID in the cookie frontend and frontend_cid, when 3d-Secure does a POST back to magento it's not allowed to read these cookies because of SameSite=Lax (or not set is treated as Lax). Because Chrome sees this as a third party request because it was POST.

This leads to Magento not knowing who you are, no order is being created but if everything went fine on the third party system the customer has paid for the goods but he/she won't receive any order because Magento isn't aware that any order was placed.

So my simple solution is to change the cookie to SameSite=None upon order placement and change the expiry time to 5 minutes. So the customer has 5 minutes to pay for the order and return to Magento. Then the cookie is set back properly to SameSite=Lax and whatever expiry time you have configured in Magento.

You could ask 3D-secure and all Banks to do GET / QueryString instead but this leaves data exposed on FE which is insecure.

Best would be if all data related to the order came inside the POST data but how is 3D-secure supposed to know all data needed for Magento and I don't see this happening any time soon.

You could also make this POST request redirect to another own controller with the same POST data but then you have just undone the added security this is supposed to add.

[colinmollenhour]

I think I understand the issue, I'm just proposing a solution that fixes two downsides to the approach in this PR:

• Using SameSite=None exposes the cookie to all third-party sources, not just 3D-Secure.
• Setting a short expiration causes a risk that the customer will lose their session. For example, they get up to go find their credit card and get distracted with something so it takes them an hour to complete the last step, then their cookie has expired and they lose their shopping cart.

So my suggestion is to instead add a new cookie that is safe to expose via SameSite=None and that does not need to expire quickly but can take the place of the frontend and frontend_cid cookies for the POST back from 3D-Secure. For example, it could be a JWT (encrypted JSON) that contains the frontend cookie values. This cookie would only be recognized by the checkout success page so that it poses no risk to other pages such as the customer's address book.

[kestraly]

This issue is now critical for 3D secure to be maintained in Chrome.

Having issues with SameSite being set, even with this added feature. Looking into it further.

[OZZlE]

Having issues with SameSite being set, even with this added feature. Looking into it further.

@kestraly You are probably not using the standard Magento checkout or you have a rewrite on Mage_Checkout_OnepageController:: saveOrderAction

You need to make sure that whatever you have uses this same logic.

[kestraly]

It was the default checkout. Didn't seem to add the SameSite tag Lax or None. Will keep digging. I put the temporary fix in place for cookie path: /;Secure;SameSite=None which does mark the cookie as SameSite None. So at a bit of a loss as to why this fix doesn't mark it as Lax or None.

[kestraly]

Should have looked into this a bit more earlier. This method only works with PHP 7.3 onwards, otherwise the example below would need to be deployed.

if (PHP_VERSION_ID < 70300) {
        setcookie($name, $value, $expire, "$path; samesite=$samesite", $domain, $secure, $httponly);
    }
    else {
        setcookie($name, $value, [
            'expires' => $expire,
            'path' => $path,
            'domain' => $domain,
            'secure' => $secure,
            'httponly' => $httponly,
            'samesite' => $samesite,
        ]);
    }

[SarunasCard]

Hello folks! Nice code you have created. What is the status? Any help needed to finish this up?

[fballiano]

is somebody using this patch in production? since it's 2 years old and not merged.

also

• adyen is the onle payment gateway that actually forbids using M1 code: PCI Compliance #975
• OM now supports configuring cookie's samesite
• this PR has conflicts

[colinmollenhour]

I say close as IMO this PR does more harm than good and there is no progress.