search

braintree / braintree-web-drop-in

Braintree Drop-in for the web
MIT License
200 stars 124 forks source link

CSP frame-src issues with 3DS #779

Closed ChrisHSandN closed 2 years ago

ChrisHSandN commented 2 years ago

General information

Issue description

We are getting a significant number of complaints from customers about the 3DS verification popup. Most say they enter in their card details, click continue and are presented with a popup which is either “white” or has the words “content is blocked”.

Looking into our content security policy error logs we can see a number of reports relating to blocked frame-scr rules from URLs which seem to be part of the 3DS ecosystem. Some of them are as follows:

We have all the CSP rules added as specified by the documentation here.

The browsers are varied but include the latest versions of Chrome, Firefox and Edge so it doesn’t appear to be an issue with a particular one.

Should Cardinal and/or Braintree be proxying all these requests so the only iframe-url a client ever goes to is your URLs?

Additional Details

jensonBuzz commented 2 years ago

Is there any update? We had to deactivate 3D secure, since no payments went through anymore.

crookedneighbor commented 2 years ago

This is what our 3D Secure team has told me:

3DS2 is based on an iFrame implementation and specifically requires full use of the issuing banks ACS (Access Control Server) URL - it is not allowed within the core technical framework to mask or redirect to this URL. In contrast, 3DS1 primarily used a redirect flow and did not have a requirement to use the issuing banks ACS URL, and we could therefore initially load an initial standardized URL then redirect to the ACS URL to allow CSPs.

It's also important to note that 3DS2 has an additional data collection flow which did not exist in 3DS1, called the "3DS Method" or "Method URL Collection", that happens via a hidden iFrame on the page and also utilizes the ACS URL. This flow happens for both challenge and frictionless flows. While optional within the overall 3DS2 technical specifications, Visa considers it mandatory, and its general usage increases authentication success significantly. Blocking this data collection via a CSP can cause a larger number of challenges and therefore increase consumer friction during checkout.

This means there is no strict CSP setup available for 3DS2 as maintaining a consistent list of possible ACS URLs for a CSP is not possible; they regularly change and are not predictable given the variances between issuers and ACS providers. If the merchant wants to maintain a CSP, they can set 'frame-src *' as part of said CSP within their checkout page so ACS URLs are not blocked within the frame.

I know this is not the best news for a strong content security policy, but it looks like that's what's required for the 3DS protocol.

ChrisHSandN commented 2 years ago

Many thanks for your helpful information; we have been struggling to get answers on the 3DS issues we have been experiencing for some time.

May I suggest that your documentation desperately needs this information included in it under the CSP section https://braintree.github.io/braintree-web-drop-in/docs/current/#content-security-policy . It even specifically recommends “considering the implementation of a CSP when available”.

I know its outside of your control, but combining frame-src * with PayPals requirement for script-src unsafe-inline sounds like a perfect recipe for rendering the CSP effective useless on the very page where security matters the most. 🤔

crookedneighbor commented 2 years ago

We have a ticket to update the documentation.

I know its outside of your control, but combining frame-src * with PayPals requirement for script-src unsafe-inline sounds like a perfect recipe for rendering the CSP effective useless on the very page where security matters the most. 🤔

I totally agree with you on this, and if anyone has ideas on how to remedy this, we're happy to try them out. As far as I know, for now, there's nothing we can do about the frame-src * bit.

For the PayPal bit, when we can upgrade to the latest version of the PayPal SDK, that requirement should be able to be removed. It's on our list of things to do for the next major version. There are, unfortunately, some breaking changes that come with upgrading the sdk, so we can't just do it right now.