TERMINALFOUR.Blog

The meeting point for digital marketing in higher education

Securing HTML5 Web Applications

Based on talks by Carlo Bonamico (“Web Application Security Reloaded for the HTML5 era”) and David Lindsay (“Level Up your Dev Skills with Static Analysis ” )at DevOxxUK 2015.

The history of application security is a long one. However, with the advent of web applications, the number and scale of attacks has increased exponentially. For over 10 years, OWASP have been publishing their Top 10 list of security vulnerabilities.

When JavaScript was first introduced by Netscape in 1995, the nature of attacks against web applications started to change. Cross site scripting (XSS) attacks began until Netscape introduced the same origin policy to combat the issue. However, XSS attacks are still number 3 on the OWASP list of vulnerabilities.

The introduction of AJAX by Mozilla in 2002, which only became fully supported by Internet Explorer in 2007, and the resultant rise of the single page application has seen a huge shift in the architecture and technology used by web applications. This change was greatly aided by the introduction of a number of JavaScript frameworks and libraries around that time, including YUI, Prototype, jQuery and Ext JS.

Here I take a look at some of the vulnerabilities in the OWASP Top 10 and provide information about how to mitigate against them.

SQL Injection

Despite all of the changes in recent years in the architecture of applications, injection vulnerabilities are still number 1 in the OWASP list. They can be mitigated against relatively easily by using interfaces that support bind variables, thus allowing the interpreter to distinguish between code and data.

Cross-site scripting

Number three on the OWASP list is XSS. It occurs any time raw data from an attacker is sent to an innocent user’s browser. In traditional web applications, protection against XSS was implemented on the server-side, through input white-listing or output encoding.

With single page web applications, all input should be validated on the server-side as well as the client-side, to ensure that client-side validation has not been circumvented. Using Handbars, Mustache or similar templates can ensure that output is safely encoded.

To mitigate against XSS attacks, a Content Security Policy (Content-Security-Policy) header should be set where possible. This provides extra security beyond the scope of the standard same origin policy. It allows you to create a whitelist of sources of trusted content for a number of resources, including scripts, plugins, form actions and child pages (frames) amongst others. While modern browsers provide widespread support for the Content Security Policy header, full support was only added in Microsoft Edge. Internet Explorer 10 and 11 support the sandbox version of the header (X-Content-Security-Policy). IOS Safari supports Content Security Policy through the “X-Webkit-CSP” header.

Authentication and session management

For authentication and security in all web applications, SSL should always be used. Google now use https as a ranking signal and are pushing their “HTTPS everywhere” initiative. As well as using HTTPS, authentication should be simple, centralized and standardized.

In addition to requiring HTTPS within your web applications, you should also use the httponly and secure modifiers. Once set, cookies will only be sent over secure HTTPS connections, meaning that session IDs are not sent over insecure connections where they can be easily intercepted.

Cross-site request forgery

While using secure connections provide a degree of protection, they don’t protect against cross-site request forgery attacks. A cross-site request forgery or CSRF attack is one in which an attacker tricks the victim’s browser into issuing a command, for instance by tricking the victim into clicking on a link or submitting a form that they think does something else. In order to mitigate against simpler CSRF attacks, no web service calls that either receive or update data on the server should rely on automatically provided credentials. Automatically provided credentials include cookies and basic header authentication amongst other things. Manually adding a cryptographically secure authentication token to the headers of submitted requests means that an attacker cannot easily forge requests. It should be noted though that if your application has XSS holes, the attacker can still spoof request.

Authorisation

As well as using a using a centralized authentication model, all pages in an application and all web services exposed by the application. A common mistake is called “presentation layer access control”, whereby the developer presumes that if only authorized links and menu choices are shown to a user, that the application is secure. This allows an attacker to manipulate URLs to gain access to services that they’re not authorized to access. Authorization to every service should be enforced on the server-side.

Known vulnerable components

One thing that’s often overlooked when verifying the vulnerability of an application to attack is vulnerabilities in components that the web application makes use of. This is further compounded by component dependencies, which may be automatically added by build tools.

Such vulnerabilities can be mitigated against by using tools like OWASP ZAP, which includes a Maven plugin to run checks on referenced libraries as part of integration tests, or by using retire.js, which includes an OWASP ZAP plugin.

Available Tools

There are number of handy tools out there, in addition to those already mentioned, that can be used to help ensure that your web applications are secure.

Many of the existing code analysis tools can already locate many security issues in code, including the findSecurityBugs plugin for findBugs, or SonarQube, which provides a number of security checks out of the box.

One of the most important parts of a secure development strategy is your developers. It is critical that your developers understand the importance of securing the applications that they deliver, both through their own development and through their code reviews. If your developers are aware of and act upon the main threats to the security of your web applications, you’ll encounter far fewer security issues after applications have been deployed.

Tagged: Application Security, OWASP, Web development

Leave a comment

Previous Post | Next Post

Comments


Back
Back to top Back to main listing

Follow Us

Subscribe via Email

Related

Back to top Back to blog home