Sunday, May 11, 2014

Tulsa School of Dev

Don't forget May 16. OUS downtown campus free training. An all day event. For more information go to ...

Client Side Coding - JavaScript

JavaScript has several known security vulnerabilities. Now with HTML5 and JavaScript becoming more prevalent in web sites today and with more web sites moving to responsive web design with its dependence on JavaScript the developer needs to understand what vulnerabilities to look for.

The most significant vulnerabilities in JavaScript is cross-site scripting (XSS) and Document Object Model, DOM-based XSS.

Detection of DOM-based XSS can be challenging. This is cause by the following reasons.

• JavaScript is often obfuscated to protect intellectual property.
• JavaScript is often compressed out of concerned for bandwidth.

In both of these cases it is strongly recommended the code reviewer, and QA be able to review the JavaScript before it has been obfuscated and or compressed.

Another aspect that makes code review of JavaScript challenging is its reliance of large frameworks such as Microsoft .Net and Java Server Faces and the use of JavaScript frameworks, such as JQuery, Knockout, Angular, Backbone. These frameworks aggravate the problem because the code can only be fully analyzed given the source code of the framework itself. These frameworks are usually several orders of magnitude larger then the code the code reviewer needs to review. Because of time and money most companies simple accept that these frameworks are secure or the risks are low and acceptable to the organization.

Because of these challenges we recommend a hybrid analysis for JavaScript. Manual source to sink validation when necessary, static analysis with black-box testing and taint testing.

First use a static analysis. Developers, Code Reviewers and the organization needs to understand that because of event-driven behaviors, complex dependencies between HTML DOM and JavaScript code, and asynchronous communication with the server side static analysis will always fall short and may show both positive, false, false–positive, and positive-false findings.

Black-box traditional methods detection of reflected or stored XSS needs to be preformed. However this approach will not work for DOM-based XSS vulnerabilities.

Taint analysis needs to be incorporated into static analysis engine. Taint Analysis attempts to identify variables that have been ‘tainted’ with user controllable input and traces them to possible vulnerable functions also known as a ‘sink’. If the tainted variable gets passed to a sink without first being sanitized it is flagged as vulnerability.

Second the developers, QA needs to be certain the code was tested with JavaScript was turned off to make sure all client sided data validation was also validated on the server side.

Code examples of JavaScript vulnerabilities.

<script type=”text/javascript”>
var pos=document.URL.indexOf(“name=”)+5;

Explanation: An attacker can send a link such as “http://hostname/welcome.html#name=<script>bad code here</script>" to the victim resulting in the victim’s browser executing the injected client-side code.

Another example:

  1. var url = document.location.url;
  2. var loginIdx = url.indexOf(‘login’);
  3. var loginSuffix = url.substring(loginIdx);
  4. url = ‘http://mySite/html/sso/’ + loginSuffix;
  5. document.location.url = url;
Line 5 may be a false-positive and prove to be safe code or it may be open to “Open redirect attack” with taint analysis the static analysis should be able to correctly identified if this vulnerability exists.

If static analysis relies only on black-box component this code will have flagged as vulnerable requiring the code reviewer to do a complete source to sink review.