Checkout, payment, CSP and 3DS

[adamlavery]

Preconditions and environment

CE2.4.6-p3 Opayo payment (eBizmarts), but could be any card payment gateway/extension.

Steps to reproduce

Try to pay with a card that uses a 3DS provider that is currently not whitelisted for CSP.

Expected result

Something is logged somewhere that the store owner can access so the developer can add the 3DS provider to the CSP whitelist.

Actual result

Customer gets a blank 3DS confirmation page while store owner has nothing to go on to know how to fix it,

Additional information

CSP is enabled for blocking in 2.4.6. The aims of CSP are laudible and indeed the checkout page, being the most sensitive on the site, should most definately do all it can to prevent injection of malicious scripts. However, when it comes to card payments, there's no way in advance to know what 3DS providers various card issuers use. Apparently, the PCI doesn't maintain an approved list of 3DS providers to refer to for whitelisting.

So what to do about this? Assuming a customer reports the issue and doesn't just go elsewhere, we cannot expect to issue instructions to end customers on how to use dev tools to check what's happening. A means of logging this issue needs to be found so that corrective action can be taken - i.e. 3DS provider service address whitelisted.

The correct approach, in advance of imposing 3DS across the globe, would have been:

1. PCI requires all 3DS providers to be approved and maintains a list of provider addresses
2. Browsers load PCI approved 3DS providers and automatically allow in CSP

But that's just how I would have approached it!

Release note

No response

Triage and priority

• [X] Severity: S0 - Affects critical data or functionality and leaves users without workaround.
• [ ] Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
• [ ] Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
• [ ] Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
• [ ] Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.

[m2-assistant[bot]]

Hi @adamlavery. Thank you for your report. To speed up processing of this issue, make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, Add a comment to the issue:

• @magento give me 2.4-develop instance - upcoming 2.4.x release
• For more details, review the Magento Contributor Assistant documentation.
• Add a comment to assign the issue: @magento I am working on this

• To learn more about issue processing workflow, refer to the Code Contributions.

  Join Magento Community Engineering Slack and ask your questions in #github channel. :warning: According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting. :clock10: You can find the schedule on the Magento Community Calendar page. :telephone_receiver: The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, join the Community Contributions Triage session to discuss the appropriate ticket.

[m2-assistant[bot]]

Hi @engcom-Dash. 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).
• 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue.
• 3. Add Area: XXXXX label to the ticket, indicating the functional areas 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!

---

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

[adamlavery]

To note: you will not be able to reproduce all issues raised on a vanilla Magento. There's probably not a single production Magento site in existence that is a vanilla instance. To reproduce this you'd need to install a hosted card payment facility and then do a test/live payment using a card that uses a 3DS provider known not to be whitelisted.

Sometimes you just have to work with the information provided. :)

[engcom-Dash]

Hi @adamlavery

Thanks for reporting and collaboration.

We have tried the below steps to reproduce this issue:

1.In admin , stores-configuration-sales-3D security - environment -standbox

2.In stores-configuration-sales - payment methods - braintree config - enable credit cards and 3DS

3.Place an order with the credit card

We were able to place the order successfully.

Please refer the attached video recording.

https://github.com/magento/magento2/assets/60198592/a9bb8192-80cb-405e-8805-e43727a66cf9

We are not able to reproduce the issue. can you please provide information on 3DS card provider which are not whitelisted for CSP and any other information that will help us in reproducing the issue.

[adamlavery]

Hi, you are failing to see the bigger picture here. What actual 3DS form gets loaded will depend on the card issuing bank and what 3DS service provider that issuer uses. We cannot know in advance all of the potential 3DS providers there are or what their service address is. Therefore we cannot add to CSP whitelist in advance. The best we can hope for is that the majority of well-known 3DS services are whitelisted.

For those that aren't, we need to know when they are blocked by CSP so we can rectify. As it stands, nothing is logged or shown to the customer - just a blank page where the 3DS form should appear but doens't because it was blocked by CSP. Hence there needs to be a means to catch this so the customer is informed and the 3DS provider can be whitelisted.

[engcom-Dash]

Hi @adamlavery

As per the above comments, we are marking this ticket as a feature request as its a good feature to have where the customer should see 3DS form instead of blank screen.

[adamlavery]

I'm not sure that allowing customers to pay online with a card should be a "feature request" on an ecommerce store! 3DS is now a fact of life; Magento must support it. It could be argued that it's the responsibility of all individual payment extensions to ensure 3DS is properly covered with any blocking issues flagged. But why make all extension developers deal with this rather than handling it in the core?

[sjongberg]

Hi @adamlavery Were you able to find a solution to this problem? In Magento 2.4.7 they changed the CSP to restrict mode for payment pages in the storefront and admin areas https://experienceleague.adobe.com/en/docs/commerce-operations/release/versions. This is a serious issue for payment gateway plugins that implement a native integration or iframes on the payment pages. @adamlavery in your case does Opayo integrate everything in an iframe? or is 3DS usually done through a redirection or pop up?

[adamlavery]

@sjongberg sorry, there's no solution to this other than setting CSP back to report mode. Following this, eBizmarts released a new version with an expanded list of CSP allowed 3DS provider service addresses. However, we can only know if this has happened if the customer contacts the store to say they can't pay. Even then, without access to the customer's browser, there's no way to tell what is being blocked so it can be whitelisted.

Opayo has multiple ways to do paments - we use Pi (or whatever it is called now) which integarates the card form into the checkout with an iframe.

In one instance we got lucky; the customer was using a Barclaycard and so was the staff member who tested. From the staff member browser I could see that, while Barclaycard 3DS was CSP whitelisted it was at a .com address and 3DS validation in the UK was done via a .co.uk address!

There needs to be a specific CSP fail log in Magneto that records all CSP failures for checking, preferably in it's own log file and not in with all the usual noise that Magento generates.

[sjongberg]

Hi @adamlavery, Ok, it's what I suspected, they do everything in an iframe and hence any redirection will potentially get blocked unless whitelisted :-(

This will be a big issue in 2.4.7, I see that Magento implemented it to be compliant with PCI 4.0 (2.4.7 release notes).

Changes to Content Security Policy (CSP)—Configuration updates and enhancements to Adobe Commerce Content Security Policies (CSPs) to comply with PCI 4.0 requirements. For details, see Content Security Policies in the Commerce PHP Developer Guide.

Checking PCI 4.0 docs, the only rule I found that could be related is the below. Says it's only best practice until 31 March 2025...

11.6.1 New requirement to deploy a change-and-tamperdetection mechanism to alert for unauthorized modifications to the HTTP headers and contents of payment pages as received by the consumer browser. This requirement is a best practice until 31 March 2025.

So Magento is a bit of an early adopter, but what does that mean after 31 March 2025, will it become mandatory?

@adamlavery there are providers that integrate in a way that should not be blocking. They might use an iframe to tokenize the card data (so only one domain needs whitelisting), then an API request is done in the backend to process the payment using the token. If 3DS is required the customer is then redirected to the 3DS page (which shouldn't cause a blocking issue as it's not rendered in an iframe).

BTW I have also seen issues with PSPs that render everything in an iframe, it's generally bad practice as there will always be potential for issues, especially with 3DS. One merchant was trying to integrate a payment page in an iframe and got complaint of white pages, and it turned that the client's browser was blocking the flow because of too many redirections, so it can also be limited by the client's and/or browser's default security settings.