Voix Security: JavaScript

Sunday, May 11, 2014

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.

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

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:

var url = document.location.url;
var loginIdx = url.indexOf(‘login’);
var loginSuffix = url.substring(loginIdx);
url = ‘http://mySite/html/sso/’ + loginSuffix;
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.

References:

http://docstore.mik.ua/orelly/web/jscript/ch20_04.html
https://www.owasp.org/index.php/CRV2_SourceSinkRev
https://www.owasp.org/index.php/CRV2_CanStaticAnalyzersDoAll
https://www.owasp.org/index.php/Static_Code_Analysis
http://www.cs.tau.ac.il/~omertrip/fse11/paper.pdf
http://www.jshint.com/about/ https://github.com/mozilla/doctorjs

Sunday, July 22, 2012

Code Obfuscation

Languages like C# and Java can be easily be de-compiled and now with more web applications using JavaScript we don’t even need to de-compile the code to see it.

Because of this, code obfuscators are on the rise. One of the newest kids on the block is JScrambler (https://jscrambler.com/) made by AuditMark (http://auditmark.com/).

Code obfuscator’s work but do they provide any value? Do they add any value, for security, protecting our intellectual property, etc.?

Obfuscated code is modified on purpose to make it harder to read and making it more difficult to analysis what the code really does. A key point here is this goal is a two way street. It can be for someone trying to protect their intellectual property or for malware trying to prevent its detection by anti virus/malware scanners. So our first point is obfuscated code can be used for and against us.

That brings up an excellent point. If your web site uses something like jscrambler should I have the right to inspect the JavaScript used by your web application to make sure it is not doing something evil? Remember the JavaScript is not running on the server it’s running on your box.

Code obfuscated makers say obfuscation provides the following benefits to its users…

Protect Intellectual property (e.g. algorithms) contained in JavaScript.
Prevent code reutilization.
Prevent code modification.
Prevent unauthorized code execution (piracy).
Add another layer of security, by making it harder for attackers to interfere with your Web Application.

This last point is the most discussed point; does obfuscated code really provide a benefit as an added layer of security? Remember code obfuscation is NOT encryption.

Yes, obfuscated code does provide extra security. We know it can be broken/reverse engineered but the time and effort it takes does provide a temporarily determent to the causal hacker. In the long-run it will not protect your code.

Before using code obfuscation I think one of the first things we need to ask ourselves is “What are we trying to accomplish with code obfuscation?” with that question in mind here are a few guidelines.

Never put sensitive information on the client (passwords, 'hidden" URLs, validation routines, encryption routines, etc).
Understand that anything on a client can be compromised because you no longer have control.
Any obfuscation of client-side code has to be un-done in order for the framework to process it... thus only providing only a marginal security improvement.

My personal take on this is JavaScript code obfuscation provides less transparency on the Web. Open transparency creates better privacy in that everyone can see what everyone else is doing in an open environment. The temporary time value of security gained by using obfuscation is not enough to overcome the potential downfall of a less open transparent environment.

A few other resources:

http://blog.kotowicz.net/2010/04/beating-javascript-obfuscators-with.html

http://getfirebug.com/

https://developers.google.com/closure/compiler/docs/api-tutorial3 Compression provides obfuscation as a side-effect.

https://developers.google.com/web-toolkit/doc/latest/FAQ_DebuggingAndCompiling#Why_is_my_GWT-generated_JavaScript_gibberish?