Preventing Security Vulnerablities - tsgrp/HPI GitHub Wiki

In 2006 Cross-Site Scripting (XSS) vulnerabilities and other web-based vulnerabilities, overtook Buffer Overflows as the most popular targets for attackers. Any large webapp, such as HPI, could be a target for an attacker if it contains such vulnerabilities. Luckily, all of the web-based vulnerabilities are preventable as long as we're careful of a few things in our code.

###Cross-Site Scripting (XSS) Client-side scripting languages generally include same-origin policies, which allow interaction between Web objects and pages only as long as they come from the same domain and over the same protocol. XSS bugs allow malicious websites to find ways around these policies, potentially accessing sensitive data in other objects or browser windows. The worst XSS vulnerabilities allow attackers to embed their own code on to a vulnerable site, which will be run any time a user views a given page.

The main way a XSS vulnerability is introduced, is if we take user input, and without validation, insert that same input into the DOM in some way. Check out this JSFiddle for an example of XSS vulnerable code: http://jsfiddle.net/1z2nq9nd/1/

Luckily many of the libraries we use are well-aware of and prepared for these vulnerabilities. Handlebars, as its main job is drop content into the DOM, does plenty of its own validation and cleaning the values being serialized as does jQuery when using the $.text() method. So for the most part, keeping our secure is already taken care of, but there are some cases we have to watch out for.

If at possible avoid using $.html() or JavaScript's .innerHtml() methods in combination with user input, or text that is pulled from the DOM. The above also applies to using Handlebar's Helpers functions to insert more dynamic html into the template. If avoidance isn't possible use Handlebar's nice, Handlebars.Utils.escapeExpression() method on any potentially user controlled variables, before passing them to $.html() / .innerHtml() / A Handlebar's Helper.

We also need to be wary of these same issues when writing content into any DOM element's "src", "href" or "background" attribute, even if its not from an $.html call. Any tag which causes a redirect or a resource to load could be a risk, so even div's "style" attributes would potentially be vulnerable.

While many of our libraries guard us from most XSS vulnerabilities, here's a longer list of things be extra careful when using:

  • Write raw HTML, e.g.:

    • document.write(…)
    • document.writeln(…)
    • document.body.innerHtml=…

  • Directly modifying the DOM (including DHTML events), e.g.:

    • document.forms[0].action=… (and various other collections)
    • document.attachEvent(…)
    • document.create…(…)
    • document.execCommand(…)
    • document.body. … (accessing the DOM through the body object)
    • window.attachEvent(…)

  • Replacing the document URL, e.g.:

    • document.location=… (and assigning to location’s href, host and hostname)
    • document.location.hostname=…
    • document.location.replace(…)
    • document.location.assign(…)
    • document.URL=…
    • window.navigate(…)

  • Opening/modifying a window, e.g.:

    • document.open(…)
    • window.open(…)
    • window.location.href=… (and assigning to location’s href, host and hostname)

  • Directly executing script, e.g.:

    • eval(…)
    • window.execScript(…)
    • window.setInterval(…)
    • window.setTimeout(…)

  • Coming soon CRLF Injection vulnerabilities:

  • And the best ways keep your cookies safe from attackers...