This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

CRV2 ClientSideCodeJScript

From OWASP
Jump to: navigation, search

JavaScript has several known security vulnerabilities, 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 code reviewer 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 review 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. Code Reviewer 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 code reviewer 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>alert(1)</script> to the victim resulting in the victim’s browser executing the injected client-side code.

# 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.


For Javascript and Session handling see Session Handling


References:

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


Three points of validity are required for Javascript codes:

  1. Have all the logic server-side, Javascript is only the butler
  2. Check for all sorts of XSS DOM Attacks
  3. Check for insecure Javascript libraries and update them frequently.


Javascript uses strings to create DOM elements. This can lead to XSS attacks. All input should be sanitized before being converted to DOM objects.

Javascript libraries are not? prone to attack. Most of them have flaws in them, recent jQuery flaw (evaluating the document.location.hash, allowing XSS to be embedded after # in location) caused Drupal (which is generally a safe system) to allow admin user creation for attackers!