Software Security

 

The sacred knowledge of securing JavaScript

JavaScript is gaining more and more popularity not just on the front-end, but also on the back-end, with new frameworks coming out almost every month. On the client-side, we are watching an overwhelming encroachment of AngularJS, which is slowly pushing out Knockout.js, React.js, and Ember.js. On the server-side, Node.js has established its base with Express as the main companion. But new web frameworks and specialized frameworks like Hapi.js, Sails.js, and Socket.io are growing like mushrooms after a good rain. And then there are the new kids on the block to consider like Meteor and Aurelia that are popular for prototyping and are beginning to make their way to real production environments.

On the other hand, cross-site scripting has been in the top 3 of the OWASP Top 10 vulnerabilities for a decade. With the emergence of DOM-based cross-site scripting several years ago, and the large amount of complex JavaScript client-side code, we are not really reducing the number of vulnerabilities. There are several reasons for that.

Reason 1: Inadequate knowledge of security development standards

There is a lot of documentation on how to use the frameworks, but there isn’t much literature yet about how to use them securely. Some good resources exist for tracking security issues and fixes, such as Node Security Project, but there isn’t a vast knowledge of security development standards and guidelines, as we have for more mature languages like Java and .Net.

Reason 2: Lack of effective automated tools

There currently aren’t any automated tools that effectively scan client-side and server-side JavaScript, performing dataflow analysis and not just pattern-matching, and understanding the thousand and one frameworks. You are welcome to prove me wrong on this one.

Reason 3: Complex dependencies between frameworks

One of the reasons why there aren’t many really good tools is because of the third reason—the complex dependencies between frameworks. Although they are open source and all of the source code is on GitHub, when one framework is built on top of another and it also uses multiple middleware components, which in turn use other libraries and packages, we are bound to get vulnerabilities such as the zero-day in the Socket.io’s dependency on Node.js.

AppSec Europe 2016

One way to find resources and educate yourself on the security posture of new frameworks and technologies is by attending one of the biggest and most technical security conferences—AppSec EU this June. Such events offer an opportunity to not only listen and learn from highly-skilled speakers, but also to mingle, argue, and discuss the issues that worry you most. And if what worries you the most is how to secure your all-JavaScript application from front-end to back-end, then the best way to do that is by attending the Defensive Programming for JavaScript & HTML5 training.

This one-day training not only discusses common vulnerabilities in Node.js, Express.js, and AngularJS, but also provides hands-on labs that allow attendees to learn best practices of defensive programming in these frameworks. Attendees will analyze the security posture of HTML5 technologies like cross-origin resource sharing (CORS), content security policy, Web messaging and Web storage, how they add to the attack surface of web applications, and how to use them in a secure way. After a full day of training, attendees will walk out with a great deal of hands-on security knowledge that is not present on Stackoverflow or in a framework’s documentation pages.

Share and Enjoy:
  • Facebook
  • Twitter
  • Google Bookmarks
  • LinkedIn