HTML5 Security Concerns — Executive Summary

With the wide-spread adoption of HTML5 and responsive web design, like any new technology, companies need to be aware of the security implications of their design choices. What we are seeing with HTML5 is a number of threats that are less of a concern to traditional web applications are re-emerging and appear to have greater impact on HTML5 applications.

Traditional Vulnerabilities Still Apply

An important thing to consider when developing HTML5 applications is that no matter where the applications are deployed, whether it is a mobile device or web application, the same security best practices for web development still apply. HTML5 applications regardless of deployment can still be plagued with the same vulnerabilities as web applications (SQL injection, cross-site scripting, weak encryption, business logic attacks, etc.). In developing in an HTML5 environment one must consider all web application vulnerabilities as well as a number of other key threats.

Cross Origin Resource Sharing

Modern HTML5 applications often make use of resources and libraries hosted within a company’s control as well as libraries hosted by other providers. It is also common for libraries to make use of shared storage locations and resources. One trend we are seeing with HTML5 applications is that they are often configured to allow resources to be used and shared among external untrusted sources. When developing HTML5 applications, if the application is processing or storing any sensitive data or transactions every effort should be made to ensure that no data is leaked to external sources. Often the mitigation strategy to prevent such data leakage is to implement technical policies/configurations to prevent the flow of data to an untrusted source. A company should make every effort to reduce their exposure in this area by limiting their dependence on untrusted code sources/libraries. If an untrusted external source must be used then the application/server making the request for external source should be restricted to only use resources from a whitelisted list of sources.

Multi-Platform Development Tools

It can be quite costly, time consuming and difficult to develop applications for a wide variety of platforms. One main appeal of HTML5 is the notion of code once, deploy many. This has led to a vast market of multi-platform development/deployment tools. These tools will often accept JavaScript and HTML5 code and produce native code for each given deployment. From our experience not all of the tools are made equal and some can actually introduce vulnerabilities into your application. If the multi-platform route is desired careful consideration should be taken to evaluate the implications of any development platform before adopting it. With growing widespread support in browsers and mobile devices for HTML5 a better route would be to deploy the applications as HTML5 applications.

Local Storage

HTML5 applications often make use of local storage in the browser’s memory space or on the mobile device. While use of this feature can make for a better user experience, all too often in our assessments we find sensitive user data throughout the user’s memory space. Developers should assume that any data put in the users memory space will be manipulated and viewed by other applications or malicious actors.

Click/Tap-Jacking (Cross Frame Scripting)

Click-Jacking can occur when a malicious user loads a window or frame on top of a running application. The malicious user then entices a regular user to perform tap or click actions that are passed through to the application running underneath the window. Often the targets of these types of attacks are financial transactions or user account management. In mobile and HTML5 applications we are seeing that the impact of these types of attacks is often quite severe as malicious users are sometimes able to manipulate any action on a user’s mobile device. The best way to protect an application from being exploited by this type of attack is to put checks in place to ensure that the application is loaded in the front most view and configure the application server to only distribute the application if it is in the upper most view. This server configuration setting is referred to as the X-Frame header options.

Previous Article
Exploiting and Defending Mobile Training — CanSecWest
Exploiting and Defending Mobile Training — CanSecWest

Salut à tous, We are pleased to announce that we will be presenting our “Exploiting and Defending Mobile” t...

Next Article
How SAMM Addresses Out-sourced Development
How SAMM Addresses Out-sourced Development

The Software Assurance Maturity Model is an open framework to help organizations implement a software secur...