How safe is it to allow JS CDNs in a HTTP content security policy?

Question

I am tasked with adding a content security policy to a whole bunch of Magento stores to protect against credit card scraping code, which can sneak in via the store admin or GoogleTagManager* when a password leaks. Many of these stores are including assets (jQuery, Bootstrap, FontAwesome) from various CDNs (CDNJS, GoogleCDN).

In order for the resources to load, I will need to whitelist the entire CDN host.** This got me thinking:

What is the likelihood that a malicious actor could get their own malicious code added to one of these CDNs?

The alternative to whitelisting the CDN would be to move each CDN resource into the store's own codebase. That'd be extremely tedious and error prone, so I'd like to avoid that if possible.

* CSPv3 solves this problem by allowing whitelisting of a specific resource path, but browsers likely won't support CSP3 for a long time as CSP2 still has limited support.

** I'm aware that the best solution here would be prevention of password leaks, but that is largely out of my control as clients regularly give marketing companies admin access to these resources.

Edit: After thinking more about this, whitelisting the CDNs themselves should not be an issue if the only objective is to prevent sensitive data from leaking to a 3rd party. That's because the CDN is only serving static files, and the malicious actor would still need to send the data to some server that can accept and store dynamic the data payload of PII/card data. Hoping that someone can validate or debunk this theory.

Answer 1

Hopefully , it will be very hard to insert clearly malicious code into a CDN.

Is CDN code highly likely not to be malicious? Yes

Should you the CDN domains be whitelisted for an ecommerce ? No (*)

It is possible that a CDN can be compromised. They have in the past (and there are many kinds of CDN, and each will have their own security practices), but I find very unlikely that a malicious file placed there.

In my opinion, the main risk would be a downgrade attack, Since these CDN usually have many versions of the libraries, an attacker that was unable to load his own code could take advantage of that in order to force it to load a vulnerable version of $LIBRARY instead of the latest one which it used. A 'vulnerable version' in this context could be for instance one that didn't sanitize parameters and allowed injecting specific javascript where only a file injection was possible before. It would require quite a deal of skill to craft such escalation, though (then any script-kiddie could copy it).

Now, if you were tasked with securing your company store(s), I would argue that you should not allow these third parties to load javascript on your site. Not as much for there being a big risk, but because it would be trivial to counter it. Suppose that the site does end up being compromised, with credit card data stolen. I would expect to be asked "You put a nice security measure (CSP) here, why did you exempt these hosts?" and "I thought it would be hard to compromise them" doesn't seem a like specially strong reason.

Perhaps you could find out a formal reason for excepting them, such as them holding X certification or passing certain security audits. This is probably what you will do for excepting the payment processor, ("it is eligible for being exempted as it is PCI-DSS certified"). But while some CDNs will probably pass that bar, here it is much easier to just copy locally the few files you need.

Having a clear policy will also be helpful when someone requests a new exemption (why won't you allow shadyhitcounter.com? You are already allowing GoogleCDN!), and requiring an approval process for adding a new script ("why do you need to load this script deprecated 10 years ago? Here, see this improved version over the sample you copied from the web").

Now, while my answer for that is a straight No if you were securing your shops, I softened it to No (*) given that you seem not to be protecting your own stores, but to be in a middle situation, such as a hosting provider struggling to secure them in a best-effort basis but no control over the content.

Needless to say, it is obviously preferable to have a weak CSP than no Content Security Policy at all. And the fact that untrusted people routinely get admin privileges seems like a security nightmare on its own!

(note that by "untrusted" I do not mean you have to be malicious, it may just mean that you have not proved that you are not a security inept)

I'm not sure how CSP-ready Magento is. In the likely event that you need to allow unsafe-inline, an attacker that could write javascript there will be able to come up with a way to exfiltrate it (even if it requires a bit of user interaction for navigation).

As important as getting a sane-enough policy, it is IMHO that you set a report-uri and actually review them somehow, as they are very likely to provide an early heads-up on any site compromise. Be aware however that there will be false positives, and impossible blocks. I have seen CSP block URLs that are nowhere to be found in the page. I ended up concluding that in some cases they must have been added by browser plugins (maybe malicious, maybe not).

Regarding the difficulty of moving the code locally, please note that -since you are apparently in control of the webserver- it would be quite easy to replace the CDN domains in the html output with the local hostname / your own domain used for cdn resources, with minimal risks.

Finally, let me link you to the I’m harvesting credit card numbers and passwords from your site. Here’s how. article by David Gilbertson. Their objections FAQ are really valuable on how a careful attacker might sneak by.

Answer 2

What is the likelihood that a malicious actor could get their own malicious code added to one of these CDNs?

I would say this is unlikely, and there is are easier ways to exploit XSS when CDNs are whitelisted.

The more dangerous thing is that CDN's host JavaScript libraries such as Angular, that perform JavaScript actions based on HTML code. So an attacker injects a framework, and some HTML that works with that framework:

<script src="https://whitelisted.com/angularjs/1.1.3/angularjs.min.js">
<div ng-app ng-csp id=p ng-click=$event.view.alert(1)>

This abuses the legimitate functionality of the JavaScript library.