Introduction

Client side JavaScript security is becoming more and more of an issue with the shift to Single Page Applications or SPAs in modern web development. There are many different libraries and frameworks to pick from when you set out to build your own SPA.

The main players at this point come out as: Angular, Backbone and Ember. This is a good read for an introduction.

Each framework approaches the problem of writing applications on the client side slightly differently and offer different trade-offs. The concern we want to address is the notion of security with regards to our three popularity winners.

Quick Security Rundown

Angular Backbone Ember
Dependencies No Dependecies Underscore and jQuery jQuery and Handlebars
CVEs 0 0 5
Retire.js 5 1 15
Security Policy No No Yes
Security Contact Yes No Yes
Security Documentation Yes No No
Security Features Yes No No

Angular

Angular is the first on our list. It currently doesn’t have any CVEs to its name and all found issues have been reported in the mailing list. Retire.js has recommendations to upgrade five different versions based on found vulnerabilities. Angular offers one page of documentation to help developers keep their code secure. There is no security policy in place. They have a contact for security issues listed on their website.

Angular handles its own templates and has no dependencies.

Angular implements their own version of JavaScript expressions which are more strict and run in a sandbox, which they call an Expression Sandbox. The sandbox is meant to maintain proper separation of application responsibilities like disallowing access to the window global object. Although not a security feature per se, being able to execute malicious code in the sandbox is one way of introducing XSS attacks into the web app.

Backbone

Next up is Backbone,which doesn’t have any CVEs either at the moment, and in fact no publicly reported vulnerabilities is currently available. Retire.js only has one version to upgrade from for Backbone.

Backbone itself doesn’t have a security policy, nor does it offer documentation on how to write secure Backbone code. Backbone requires both jQuery and underscore. jQuery has public CVEs and if theres space Ill dive into jQuery a little at the end.

Backbone doesn’t have any concept of an Expression Sandbox because it is much simpler in scope. It’s up to the application developers using Backbone to take care of JavaScript expressions that get placed inside templates.

Ember

Lastly we have Ember. Ember has these publicly listed CVEs:

Retire.js has fifteen Ember versions to upgrade away from mostly based on the CVEs that have been publicly released and issues that have been posted to the mailing list. Ember has a security policy on their website and a security response contact.

Ember doesn’t implement an Expression Sandbox either, and again it is up to the developer to use JavaScript expressions appropriately when inserting into client side templates.

A note on client side templates

Client side templates are where injection attacks to the DOM are most prevalent. All three libraries are vulnerable to this by differing degrees. Both Backbone and Ember use other libraries to handle their templates while Angular uses their own templating system.

There is an excellent reference for client side templating security in mustache-security. They provide a ranking system for how secure a templating system is based on what features of Javascript it is using.

  • {}SEC-A Are template expressions executed without using eval or Function? (yes = pass)
  • {}SEC-B Is the execution scope well isolated or sand-boxed? (yes = pass)
  • {}SEC-C Can only script elements serve as template containers? (yes = pass)
  • {}SEC-D Does the framework allow, encourage or even enforce separation of code and content? (yes = pass)
  • {}SEC-E Does the framework maintainer have a security response program? (yes = pass)
  • {}SEC-F Does the Framework allow or encourage safe CSP rules to be used (yes = pass)

Here’s how our frameworks match up. We’ve included underscore instead of Backbone, since Backbone depends on underscore for its templates. Ember depends on Handlebars for its templates, but introduces a layer between it and Handlebars, hence why Ember is included in our list and not Handlebars.

Framework {}SEC-A {}SEC-B {}SEC-C {}SEC-D {}SEC-E {}SEC-F
Angular (1.4.0) Fail PASS Fail PASS PASS PASS
Ember (latest) Fail PASS PASS Fail PASS TBD
underscore (latest) Fail Fail PASS Fail Fail Fail

There are wiki pages for each template system shown above which has a wiki page with excellent breakdowns of actual attacks for all three systems.

A second note on authorization and authentication

With all three frameworks it is necessary to perform authentication and authorization checks on the server. The client can’t be trusted. That being, said it is possible to add client side checks to stop average users from seeing routes they shouldn’t.

All three libraries provide a router for changing the view and none of them provide functions for authenticating or authorizing. It is up to the developer to implement these concerns.

Bonus Round: jQuery

jQuery is a hard dependency of both Ember and Backbone. jQuery is the basis for how both these libraries interact with the DOM, and so DOM based injections are affected by the security of jQuery code.

jQuery has these public CVEs:

  • CVE-2007-2379
  • CVE-2010-5312
  • CVE-2011-4969
  • CVE-2012-6662
  • CVE-2013-4383
  • CVE-2015-2089

The only recent CVE is for a plugin and not the jQuery library itself, the rest are too old to be a big concern.

jQuery doesn’t have a security response contact or a policy in place to handle vulnerabilities.

The main tip for jQuery is to sanitize any user input that gets placed back into the DOM, much the same as any of the templates for the three libraries above.

Summary

It’s hard to say one library is more secure than the other. They all solve similar problems in different ways with different design choices.

My recommendation comes down to being aware of the limitations and design decisions that are thrust upon you when you pick one of these three libraries.

The general recommendations are still the same for client side JS security:

  • Access control, input validation and security decisions must be made on the server.
  • Handle untrusted data with care — use contextual encoding and avoid building code from strings.
  • Protect your services
  • Learn how to use security HTTP headers

Sources:

Received the Following Update from Stefan Penner from the Ember Community on October 31st, 2016

{}SEC-A Are template expressions executed without using eval or Function? (yes = pass)

Ember has never used eval for templates, they are compiled at build-time, and the compiled output is safe-only DOM mutations.

> {}SEC-D Does the framework allow, encourage or even enforce separation of code and content? (yes = pass)

code + content is separated in ember by virtue of having only logic-less templates.

> {}SEC-F Does the Framework allow or encourage safe CSP rules to be used (yes = pass)

ember provides CSP support via the build harness (ember-cli), so developers can use (from day 1) be in a CSP enforcing world.

> Ember doesn’t implement an Expression Sandbox either, and again it is up to the developer to use JavaScript expressions appropriately when inserting into client side templates.

All input to templates are safe-by-default, depending on the context they will escape appropriately. In-addition, as the templates are without logic, no unsafe expression are possible.

It is likely a good idea, to either update the blog post, or provide a notice that the article is not accurate.

White Paper - Proving Adherence to Software Security Best Practices

White Paper - Proving Adherence to Software Security Best Practices

Industry standards and the best practices for developing secure software. Please provide your email and name to receive your copy.

Success! Your copy is on the way.

eight-myths

The 8 New Deadly Myths of Application Security

If you want to get clear on the best strategy for software security in your organization, you must first get clear on the problems. Many organizations identify the problems as cryptography, insecure SSL practices, or authentication issues.

This is why organizations get trapped within incorrect mindsets to find themselves struggling to prove proper adherence to software security best practicesor worse, in a middle of a data breach.

Enter your name and email below to understand the myths and start an application security program that works.

You have Successfully Subscribed!