3D Secure Iframe Content Security Policy

[Mneroen]

For the 3D Secure iframe to show i had to enable lots of URL-s in my Content Security Policy iframe-src.

If you don't enable these URLs the browser will block the 3D Secure modal with the following error: "Request to the server have been blocked by an extension error"

URLs for 3D Secure iframe to work:

• 3ds-secure.cardcomplete.com
• ecclients.btrl.ro
• bofp.erstebank.hu
• www.clicksafe.lloydstsb.com
• pay.activa-card.com
• 3dsecure-1.wirecard.com
• 3dsecure-2.wirecard.com
• acssv.otpbank.hu
• acs.sia.eu
• idcheck.acs.touchtechpayments.com

Are there any more URLs for the 3D Secure modal?

[crookedneighbor]

Thanks for the report. Looks like our 3ds secure partner made some changes without telling us 😞 .

We'll escalate to them and see if we can mitigate this kind of breaking change in the future, I have a few ideas, but want to experiment and see if they are viable.

[Mneroen]

5 more URLs:

• sicher-bezahlen.sparkasse.at
• secure5.arcot.com
• www.securesuite.co.uk
• bred.wlp-acs.com
• bnpp-3ds.wlp-acs.com

We have another problem. Not every URL works, www.securesuite.co.uk is unreachable for my customers even if i enable it in the content security policy. They can’t pay even if they want to. They get an empty 3D Secure iframe.

[crookedneighbor]

Reach out to our support team so we can report that to our MPI provider: https://help.braintreepayments.com/

[ghost]

@crookedneighbor is there any solution coming soon? /an exhaustive list of URL's to whitelist? This is affecting a lot of our customers, and we've had to disable 3ds in the meantime.

[crookedneighbor]

We are actively working on it.

We do not have a list of all impacted URLs, as the world's issuing banks are responsible for their part of the 3DS workflow and they can change their integrations at any time.

We're exploring serving all of Cardinal's code in a Braintree hosted iframe, but we want to be certain of 2 things:

1) this does not hamper any of Cardinal's code because of it being run within a BT hosted iframe instead of the merchant's page. My assumption is it does not, and in our sandbox testing, it made no difference, but I want confirmation from Cardinal before we release this change into production.

2) that the bank urls in question can be served within a nested iframe. If Cardinal is serving them at the top level instead of within their own iframe because the bank is doing something funky that prevents it from being displayed, then making this change to put everything in a Braintree hosted iframe would not solve the CSP issue and break 3ds for these banks for all merchants not using a CSP.

We've reached out to Cardinal and have communicated the urgency behind the scale of this issue, and we are coordinating with them on next steps. We'll post updates here as we receive them, but we expect investigating and resolving this issue with Cardinal to take some time.

Temporary Workaround

~As a temporary workaround, if you're using the latest sdk, you can remove songbird.cardinalcommerce.com and songbirdstag.cardinalcommerce.com from your script src directive in your content security policy. This will prompt the Braintree SDK to fallback to the v1 flow (which occurs within a Braintree hosted iframe).~

~We'll update here when that workaround can be removed, either because Cardinal fixed the underlying issue on their end or we have released a new version of the SDK that works around it on our end.~

Update: June 8, 2020 - Instead, contact Braintree support (https://help.braintreepayments.com/) with a link to this issue and say you need Cardinal to update your EAF settings.

[ghost]

@crookedneighbor Thank you for the quick update!

We'll implement the temporary workaround and look forward to the release!

To clarify, does this require both the latest Client & Server SDK, or just the Client SDK?

[ghost]

Hi @crookedneighbor - we've tried the above solution and we're still facing issues (updated web client (drop in) to 1.22.1).

We're still getting CSP violations from frame-src - example verify.monzo.com our frame-src: frame-src ssl.kaptcha.com assets.braintreegateway.com *.paypal.com;

Is there something we're missing, and is there any update on a release to fix the issue?

[crookedneighbor]

@dcwaite are you experiencing the exact same issue? or is it manifesting differently at all?

If it's the exact same issue, can you share your script-src rules?

If it's manifesting differently, that would indicate to me that there could be an issue with verify.monzo.com (and other bank acs urls).

Regardless, please contact our support team so we can look up TXN ids to send to our MPI provider for troubleshooting.

https://help.braintreepayments.com/

is there any update on a release to fix the issue?

We are doing 2 things:

1) Working with our MPI provider to see if they can fix the underlying issue on their/the bank's end 2) Writing a workaround to address this on our end.

The holdup with our workaround is it's not clear if releasing this would affect how often the challenge is shown, and if the underlying issue is actually on the individual bank's end, which could result in problems with CSP users as well as those without a CSP.

Hoping to drop a pre-release script here for y'all to try. That way we can at least verify if our workaround would be effective.

[ghost]

@crookedneighbor Off the top of my head they are exactly the same, however now, we have removed the cardinalcommerce urls from our script-src, so in addition to the above we are getting those violating our CSP.

Our script-src: script-src *.paypal.com js.braintreegateway.com assets.braintreegateway.com;

From my understanding our client isn't falling back to the v1 of 3DS?

Thanks a lot for the update!

[tomasmrazko]

@crookedneighbor Same problem for us. Braintree trying to load 3D secure form from external domain (every bank has own domain for this purpose).

Allowed sources by content security policy (using hosted fields): .braintreegateway.com .braintree-api.com *.cardinalcommerce.com

I tried suggested temporary solution, but without success - braintree still loads form from bank specific domain.

Is there some progress in solving this (big) problem?

[piotrantosik]

We also have this problem, but the strangest thing is that we don't use Content Security Policy headers. The end customer has a blocked 3ds confirmation window, we use hosted fields sdk.

[crookedneighbor]

@piotrantosik that indicates either:

A) the customer has something on their end that is blocking it, such as an overzealous ad blocker or virus scanner B) there is a problem with a specific set of banks

If it's happening for many customers, it's likely a problem with the specific banks and the best step is to contact https://help.braintreepayments.com/ and work with our support team to get the info we need to send to our MPI provider to investigate it.

[ghost]

Hi @crookedneighbor - are there any updates on a solution?

[Marczerwinski]

Hello @crookedneighbor, what is the estimated time in which bug with several banks will be resolved ?

[crookedneighbor]

Cardinal has determined the underlying issue.

To resolve it, contact Braintree support (https://help.braintreepayments.com/) with a link to this issue and say you need Cardinal to update your EAF settings.

We're working with Cardinal to make this update automatically, but contacting support will expedite the process.

[crookedneighbor]

After your settings are updated, you can remove the temporary workaround mentioned here: https://github.com/braintree/braintree-web/issues/497#issuecomment-629387577

[crookedneighbor]

Cardinal should have fixed the underlying issue, so I'm going to close this now.

[tomasmrazko]

@crookedneighbor Yesterday our customer experienced problem with 3D secure verification - due to our Content Security Policy we blocked loading 3D secure verification form from domain acs.touch.tech. Today another customer reported same issue (unfortunately without providing domain failed to load).

Any suggestions to solve this situation? Is there any list of domains that we should allow in our CSP?

Thanks.

[wjdp]

We're seeing the exact same issue, domains like:

• rsa3dsauth.com
• verify.monzo.com
• secure4.arcot.com
• paiement2.secure.lcl.fr
• danskebank-3ds-vdm.wlp-acs.com
• verifiedbyvisa.sparkassen-kreditkarten.de
• The list goes on…

It's impossible to whitelist them all, each bank will have it's own or multiple hostnames. The fix before was Cardinal (provider of 3DS to braintree) to proxy these iframes through *.cardinalcommerce.com.

[crookedneighbor]

This is the info I got from our 3DS team around this:

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 that's not great in terms of keeping up a CSP, but it is an unfortunate reality for the 3DS 2 protocol 😞

[juanmirocks]

Since recent more customers are experiencing this same issue (which never happened before). They all seem to require different URLs. I guess more banks / CCs are now finally moving to 3DS 2.

Thank you @crookedneighbor for providing the extra information you have. Is there for now any alternative to setting frame-src *? That's really not secure :(

If there is no alternative for now, this "new requirement" should be specified in: https://braintree.github.io/braintree-web/current/#content-security-policy

[crookedneighbor]

The content security policy documentation should definitely be updated to make this explicit. I've created a task to do so (though PRs are always encouraged)

[crookedneighbor]

@cvenchong please reach out to our support team about that. As far as I know, we cannot do that at this time, but our 3DS team may have more details about it.

https://developer.paypal.com/braintree/help

[salvedreyes]

Hi fellow Braintree customers. Has anyone set the 'frame-src *' in your respective CSP? We might resort doing it but still thinking of the potential risk. Just want to get some feedback. @crookedneighbor Appreciate to get your inputs as well.

[ejellard]

@salvedreyes We have tried both * and * data: blob:, and they didn't help with some browsers/banks - and frustratingly, no reports about what's being blocked.

[salvedreyes]

@salvedreyes We have tried both * and * data: blob:, and they didn't help with some browsers/banks - and frustratingly, no reports about what's being blocked.

Thanks @ejellard This is going to be an ongoing pain for all of us then. :(

[ukguy]

Was there a resolution for this? We are having constant issues with blank 3D secure boxes?

[jesse-thomann-talogy]

Still experiencing same issue here, checking in to see if there is a resolution.

[ukguy]

Still experiencing same issue here, checking in to see if there is a resolution.

We had to change the CSP to report only to avoid the issue as there is no way to whitelist or even know all the urls for the banks

[jesse-thomann-talogy]

Will consider report only but our application gets scanned regularly for security vulnerabilities and it seems changing to report only will get flagged. There has to be a better solution than "make your site less secure so that you can do more secure payment authorization"

[ukguy]

I agree but when you've got a client who turns over 5 figure sums a day wanting 3D secure to work it's the only option until there is a viable solution. The CSP whitelists domains which can load on the site, unless you know all those domains there's no way of whitelisting them to allow via the iframe. I wonder if you could keep CSP on but allow all domains only for the iframe policy. Yes, not ideal but something.

[jesse-thomann-talogy]

I agree with you, we are going to have to go this route to get payments working and deal with security scan problems as they come until there is a viable solution. Really I'm just curious if Braintree is actively working on a viable solution as this thread has gone a bit cold.

[ukguy]

The enhanced "gene commerce" version of the braintree module is now the core version, but Gene are "Magento Partners"

Neither Gene or Braintree seem interested in this issue. (but if more people push it through support tickets maybe they would be)

I get the impression when CSP was added noone thought about what you could refer to as "dynamic" payment urls for 3D. It's logical that none of us would ever know all bank urls and the banks will never cooperate, they will change urls as and when they wish. Therefore, if only there was a solution to let any urls through for iframes JUST on the checkout page. At the moment when we create the CSP module it applies it sitewide. Maybe someone who knows better could tailor the module more specifically. (if possible)

[Nthan]

I'm still experiencing CSP