Friday, 15 February 2013

CDN is Watching (over) You!

For an internal project at Astyran, I needed to dig deep into the Dojo Toolkit. After studying the extensive documentation and examples, I got slightly annoyed: nearly every example uses a Content Distribution Network (CDN) to load the Dojo JavaScript. No warning whatsoever about the risk.

What is that risk again? If your security manager hires me our some of my friendly colleagues to look into the security of the application, the use of a CDN for JavaScript will be in our report as a high rated security issue.

Code included from a third party will run in the browser with all the rights and privileges of the users of your application

Just as your own code, hosted on your server. Immediate problem is that this code hosted at the third party must be protected at the same level as the code hosted on your own server. But there is much, much more.

Nothing is new, but just as with Cross-Site-Scripting and SQL Injection, it might take some time to make developers aware of the issue.

Note: this blog is only about the problems related with using a CDN for JavaScript libraries and is not relevant to you if you use a CDN for the whole site.

Really?

I hear you. Your manager is telling you that clouds are secure now because he or she had some drinks with an anonymous some-one from a marketing department of a cloud service-provider at a conference where the sky is indeed the limit for clouds.

No problem. It is not my task to spread FUD (fear, uncertainty and doubt). It is quite the contrary: I hope to take away the fear, uncertainty and doubt, and make it possible that you make an informed decision. If the decision is that your scripts can still be hosted at a CDN, fine. Business is all about taking risks and accepting the consequences.

But if that decision is not based on knowledge of facts, it might be the wrong choice. So spare me some time, and I’ll tell you all about the risks and attack vectors of using a CDN for JavaScript hosting.

My Problem

If you read between the lines at the site, Dojo does not really recommend using a CDN, yet we have seen it many times in production set-ups. Dojo even documents how to use a CDN and custom (local) code.

Note that I just present Dojo as an example, lots of other frameworks do exactly the same.

Developers like to reuse code: any bad or good example on the web will be copied sooner or later. The Dojo examples will be copied into production applications without thinking about the risks.

Advantages of using a CDN for JavaScript

According to Google a CDN (well, only their own of course) provides your applications with stable, reliable, high-speed, globally available access to all of the most popular, open-source JavaScript libraries.

Basically, if multiple sites load the same code, it will already be present in the cache of your browser. Another cause of faster loading times might be that browsers artificially limit the number of HTTP connections to the same site, using a CDN might thus be faster at the expense of an additional DNS request.

There are plenty more CDNs than Google of course, such as code.jquery.com, ajax.aspnetcdn.com, yandex.st, yui.yahooapis.com, cdnjs.cloudflare.com …

The perceived speed advantages might however be much less than you hoped for, please refer to some of the links at the end of this blog.

Show Me

In the case of Dojo, the code would look as follows:

<script src="//ajax.googleapis.com/ajax/libs/dojo/1.8.3/dojo/dojo.js"></script>



Down Down, Deeper and Down


Simply put:



  • If the CDN is down, so will your application
  • The maintenance schedule of the CDN is not synced with the availability requirements of your application
  • There are no service level agreements
  • Good luck in contacting the support organisation of the CDN  

It is possible to do a client-side fall-over if the CDN is not available, but this might be trickier than you imagined and might ruin all possible speed advantages.

When a CDN is down, your concerns are not necessarily theirs. They will bring systems back online according to their own priorities. Meanwhile, customers are hammering your help-desk or staff are checking their Facebook when the internal application went down. 

Start by directing your Legal Team to the Terms of Service for the Google Hosted Libraries, the Microsoft AJAX CDN, the Yandex JavaScript Libraries, … 

 


Blocked


No, I am not talking about Minecraft. But access to the CDN might be blocked in countries where your customers are.


Google gives some insights into their transparency report, but unfortunately not detailed enough to verify if there are problems for the JavaScript library hosting.  I have no data for other providers. Are you prepared to accept the risk that your application does not work because of some problems between governments or a government and a CDN?


Maybe you created a nice intranet application, using a CDN for the JavaScript libraries, but were unaware that not everyone in the organization had internet access?


The wrong site of the track


The CDN might track the users of your application. Depending on the type of application these might be customers, partners or employees.At the very least the CDN will know where those users are, will learn that some users are employees, learn about your business partners, …

Some application specific information might be inadvertently leaked to the CDN in the HTTP Referer header. Some examples that we witnessed: language of users, user-id, role (e.g. admin), sex. This might not be a big privacy issue but some of the data might be interesting for marketing companies, blackmailers or criminals.

A CDN can even track users of your application to the individual level e.g. when tracking cookies are set for tracking purposes across domains.

This might have interesting consequences when the application is a Swiss e-banking application and the company that owns the CDN is incorporated in a different country where the government wants to investigate potential tax evasions.


Talk to the Hand


A CDN might suddenly stop providing a specific library resulting in a costly new release cycle.

The URL of the CDN might change and the development team might not be aware of this (or forget to include this in the maintenance release). Sooner or later disaster will strike.

 


Knock Knock, Who’s there?


CDN hosted JavaScript that is imported in the browser can access anything in your application with all the rights of the user (think CSS, CSRF, click-jacking, ...). This makes the CDN an important target for attackers.

Attacking the CDN might be easier than attacking your application. Even if most people consider the big CDNs as secure providers, there is not really any proof of this let alone hard contractual agreements. In the case of a JavaScript CDN: these are publicly available scripts, how much access control is needed for security? As much as your financial application? 

A study (broader than just JavaScript libraries) of the top 10.000 sites in Alexa found that in several cases sites hosting JavaScript were less secure than the sites that included the scripts.    

Attackers can be the admins at the CDN, successful attackers of the CDN or someone attacking the DNS at the client workstation or home-router. A few months ago millions of home-routers where hacked in Brazil and the DNS resolution for the Google domain was modified.

DNS attacks might also be something simple such as taking over a registered domain when it expires. Even large companies sometimes forget to renew their DNS registrations on time. Such expiration may also occur when the CDN host “moves up” from a .org or .net domain to a .com version.

The above mentioned study found 47 domain-names that were used for script inclusion but were not registered anymore. In 6 cases it was a mistake in the spelling by a developer. It is very easy for an attacker to register those domains and deliver malware.

Cybersquatting can also be an issue: an attacker sets up a copy of a well known CDN site but with a slightly different name (e.g. https://ajax.examlpe.com/ instead of https://ajax.example.com/) and then refers to that new name on Internet forums or discussion groups. Chances are that sooner or later people are going to fall for that (using copy/paste from a “tutorial” on a reputable CDN).

Granted, if the DNS can be attacked, a criminal can do some direct damage already (e.g. intercept authentication,…). However you might have very strong controls that makes this impossible, e.g. using public key pinning or even not using DNS.

But maybe the attackers did not target you, so you might be an innocent bystander. Still, the result might be that the computers of staff, partners or customers get infected by malware.

If not using HTTPS for the CDN a simple man-in-the-middle attack would be sufficient to do serious damage.

 

Don’t be a Tool


At Astyran we use several automated tools that scan for cross-domain script inclusions. As always, be aware of what your tool can and cannot do.

Look at the source-code of Skipfish (config.h). Skipfish is a fantastic security scanner for web applications. 

/* Domains we always trust (identical to -B options). 
These entries do not generate cross-domain content inclusion warnings. NULL-terminated.
*/

static const char* always_trust_domains[] = {
".google-analytics.com",
".googleapis.com",
".googleadservices.com",
".googlesyndication.com",
"www.w3.org",
0
};

As you can see the Skipfish tool will not alert you if content from the above sites is included in the application. Do not forget to change this code before compilation if you prefer that your customer makes the decisions about who to trust and not the developers of Skipfish.


Yes, I am Guilty


Remind me that I have to check my own sites for CDN hosted JavaScript libraries.


Conclusion



  • Do not use CDNs for JavaScript libraries.
  • Enlighten your managers that the problem is broader: web analytics, dynamic ads, tracking also include third party hosted scripts in your application (but many of them already accepted the risks here)

References


Some references for your reading pleasure. At the request of some of my readers, I explicitly repeat the link to the web-sites where the text can be read or downloaded: if this blog is printed, people can still see the full link.


3 comments:

  1. Another cool blog entry: been a while! ;-)

    Your zoompf reference illustrates that even the (perceived) biggest reason for using a CDN (speed due to scripts being cached) may not even be that big of advantage to begin with.

    On a side note: analysing local versions of standard javascript libraries can be interesting because of compression techniques that are used to reduce the size of those scripts (removing optional whitespace and comments, change names of variables and functions to much shorter names...)

    ReplyDelete
  2. Maybe JSBEAUTIFIER (http://jsbeautifier.org/) can help?

    ReplyDelete
  3. Thanks for sharing your thoughts. I really appreciate your efforts and I am waiting for your further post thanks once again.


    My blog post; proxykat

    ReplyDelete