What security considerations / concerns should be addressed when using CDN hosted code?

Question

Working on a major financial company's website, we tend to shy away from using the CDN-hosted versions of the jQuery library used throughout our site because of "security concerns".

I'm assuming (although I've never had it fully explained) that these concerns relate to potential physical security threats through the risk of code being compromised on Google's or Microsoft's servers, reputation risks through those CDN networks becoming unavailable (thereby rendering the functionality on our site useless) and any other inherent risks that might arise from these situations.

My question is - how valid are these sorts of security concerns and what might be done to mitigate any security risks found on CDN-hosted networks?

Answer 1

I guess that security of their servers is much better than security of your server, but the amount of attacks on their servers is much higher than amount of attacks on yours.

If you don't use any CDN for all images, styles and so on, so don't use CDNs at all. It's just a single file, so it won't make any big difference for you and users of your site.

Answer 2

You should look at the terms and conditions, if any, for the free-CDN-hosted versions. However, for "a major financial company" it probably won't be good enough.

If you want to use a CDN, how about getting a contract with one of them and just use your own "CDN hosted" version? CDN bandwidth is surprisingly affordable.

Answer 3

With respect to CDN networks becoming unavailable: that's highly unlikely, and the availability percentage will likely be higher than your own network. You can argue that hosting it yourself would at least ensure that the only downtime is when your systems are malfunctioning so that cross-section of network failures causing issues is smallest.

With respect to security: the data could be compromised, or the channel of transmission could be intercepted and malicious code transmitted in its place via XSS and CSRF attacks. The likelihood of this is again very low in my opinion.

There are also cookie concerns and secure connection concerns (over https instead of http) with respect to warning messages and not-matching certificates (see http://idunno.org/archive/2009/09/16/quick-thoughts-on-the-microsoft-ajax-cdn.aspx). Microsoft does support SSL, though I'm unsure about Yahoo and Google (they ought to). Google doesn't track with cookies but they'll still see IPs hitting their CDN network and could use that for tracking if they so choose.

The value of CDN would be some speed through the local caching of the script if the user visited some other site using the CDN. But for a major institution, I don't see the need.

Answer 4

If you're only using them as JavaScript includes, and as JavaScript is only client side, it potentially has access to anything and everything that gets rendered as XHTML through the DOM. This would be based on if the CDN got hacked and the JavaScript you were including got altered maliciously. See http://stackoverflow.com/questions/129053/how-does-googles-javascript-api-get-around-the-cross-domain-security-in-ajax for info on JavaScript being used cross-domain.

As others have said, it simply isn't worth the risk considering the almost zero advantages. JavaScript libraries are generally too small to matter about saving server space/bandwidth/access speeds/etc...

Answer 5

Once the user logs in I would try avoid any sort of client scripting except where ABSOLUTELY necessary. Here are the recommendations I would recommend for web work regarding online financial services:

1) Send ALL assets to the user via HTTPS from the same domain. Although it is slower and most costly for the bandwidth it is also more secure because you control all the assets from manipulation directly. By all assets I really mean all assets even including images since manipulation of images containing text content could be used to send false instructions in advance of a phishing attempt. In this regard I would not use a CDN to store your assets, because that is not a location that you own so you have less control to monitor the stored data for tampering.

2) Do NOT use AJAX or anything else with XMLHttpRequest object. The point of asynchronous communication is to beacon information between points outside of reloading a page. That is great for usability, but completely defeats security. Since it executes on the client side compromised code can also be used to defeat legitimate SSL encryption by beaconing information from the user to an untrusted third party after the information is decrypted at the user's end. When dealing with purchases, PII, or financial data ALWAYS ensure each information transaction from the user forces a page reload or a new page.

3) Avoid using any sort of client side scripting. The means do not use ActiveX, Flash, or even Acrobat at all. 95% of all reported security vulnerabilities are attributed to client side scripting and 70% of those attacks target memory corruption of the processing software. Although JavaScript is not normally known for buffer overflows I would still recommend using it as little as possible to manipulate the DOM only.

4) Never pass an anonymous function as an argument in a function or method in JavaScript. This is not something that commonly occurs, but in the case of certain built in methods this can allow a hole through the JavaScript interpreter to the processing software, which could then be an attack vector to insert code necessary to cause a buffer overflow.

5) Do not use the onsubmit event to attach script execution to the submission of form data. Violating the executing code, or appending extra malicious code, can create a point in which to include the XMLHttpRequest function to anonymously beacon the form data to an untrusted third party in advance of sending it to the trusted source even if the transfer protocol of the action attribute is HTTPS.

6) So long as you stick to VALID XHTML, CSS, and text for nearly all possible aspects of the user experience and communicate using only HTTPS you should be mostly fine.

You have to keep in mind that banks and educational institutions receive 40% of all known attacks, so you MUST assume your work will be attacked and compromised. The average cost of a single attack in 2008 was $11.3 million. If the bank could attack you for those damages, because you did not consider the full depth of security, how would you respond? Plan accordingly to ensure your work is as locked down as possible.