As we delve more into building sites and applications with HTML5 and related APIs, we’re finding certain inevitable issues arising from security practices – or lack thereof – when managing these new technologies. The more complex and secure our applications and sites need to be, such as for finance and banking, the earlier we need to understand where the risks are and implement a plan appropriate for our given projects.
In order to make some sense out of which parts of HTML5 can be used with confidence and to identify the areas where risk might occur, let’s revisit what makes up what we’ve been calling HTML5 for these past couple of years.
- Structural semantics: Additional elements and attributes for enhancing the structuring of content within a site or application.
- A range of APIs allowing scripting access: Along with the now familiar trio of Audio, Video, and Canvas APIs in HTML5 come a lot of extensive APIs permitting all kinds of application interactions, data exchange, and improved server-client relationships.
To be accurate, many APIs that began within HTML5 have since moved outside the HTML5 spec at the W3C and into working groups of their own. Some emerged from other working groups as well, both in and outside of the W3C.
In this sense, the term HTML5 is a bit of an umbrella, covering a group of related technologies and specifications. It’s important to be aware that HTML5 and “friends” are under constant change and scrutiny, and this is in part where confusion arises. As such, let’s stick with the guidelines I set out here.
Where You’re (Mostly) Safe
Unless you’re adding some kind of external scripting to the basic structural elements and extended form semantics, both of those areas can be deemed quite safe with one main exception: the uploading of files from a form to a server.
Clearly, this process can pass problematic or infected executables to the server.
The good news is we’ve known about this type of problem for a long time, so ensuring the type of files allowed for upload, running server-side virus or malicious script applications and so on can readily put a stop to the majority of these kinds of exploits.
Data in the Client
Several exciting additions to HTML5 include sessionStorage, localStorage, and client-side databases. Each of these features allow developers to provide highly responsive applications that can store data by session, across sessions and tabs, and, with databases, keep stored client data on the client.
In terms of the power this brings developers, there is no question that data handling in the client is becoming ever more efficient, allowing for more sophisticated interactions as well as offline applications. A good example is the offline Gmail application that allows you to work on email offline. Such rich features can only increase this type of client to server apps, and there’s a lot of interest in this area as you can imagine!
With the storage facilities in a browser, however, come a few challenges:
- Data isn’t encrypted as it is stored to disk, meaning anyone with direct or remote access to that computer can extract potentially private or sensitive data.
- Data stays on the disk unless the developer expressly sets up a means for it to be removed, or the user knows to do this. If neither happens, again, unencrypted data sits on the disk available to anyone with access.
- Client databases can be hacked! The are two primary client databases in HTML5 are SQL and index.db.
Clearly, having a database security specialist on an apps team is starting to look like an inevitability, particularly if you are building apps for the consumer marketplace, where financial and private data are regularly stored.
Security of HTML5 and Related APIs
In late 2011, the European Network and Information Security Agency (ENISA) studied numerous HTML5 and related APIS, identifying 51 security threats in total. Almost all of these are focused around a core of APIs, which we get to in a minute.
HTML5 and the expansion of APIs cracks open the browser to developers, allowing myriad ways of getting scripting restructuring of the browser. That means we should expect new issues we have not encountered before. There is great promise and hope in HTML5, and many people are hard at work worldwide to find solutions to these issues that will provide a more secure framework. In the meantime, we as decision makers have to take the most pragmatic, safe view in how we approach these technologies.
Cross Origin Resource Sharing (CORS)
The CORS API is an interesting case because it breaks a known policy, or design pattern, within computing. The same origin policy restricts scripts running on the same site to access methods and properties, and prevents access to those running on a different site (different origin).
CORS breaks this policy and allows resources to be accessed across domains. Ideally, this gives developers access to any number of external APIs or other features on different sites or within other applications, usually with the intent of aggregating content.
The primary risk with CORS is that content can be revealed that perhaps shouldn’t be. The CORS specification itself has a series of recommendations for best practices surrounding cross-origin sharing, and is worth a look for the security-minded reader.
This is a malicious trick to get users of a site or application to click on something different than what they think they’re clicking on, usually in an attempt to load other pages or to encourage them to type in private information.
Familiar click-jacking exploits include:
- Tricking users into enabling their webcam and microphone
- Fooling users into making their social networking profile information public
- Making users follow someone on Twitter
- Forcing shared links on Facebook
As with CORS, some steps can be taken to reduce click-jacking threats. Protection services come either server-side, or developers can use NOSCRIPT in accordance with the latest specification.
Geolocation and Privacy
Geolocation is an example of an API that sits outside HTML5 but clearly works with it for location identification. As many readers are aware, geolocation is both extremely useful and extremely disconcerting.
On the powerful side, geolocation allows us quick and easy access to directions while driving or using public transportation, as well as providing emergency services should they be required – all very helpful in this fast-paced, motorized world. On the other hand, geolocation can reveal a lot of private information about us – such as where we are, who we’re with, and so on.
The good news is that the majority of geolocation use requires users to opt-in. Good browsers and apps allow this to happen once per session, or to always log in with location services on. This can be confusing to users who are unfamiliar with the privacy concerns involved with Geolocation.
A lot of work is being done by all the major browser vendors to correct security flaws in HTML5 in general, and specifically in Geolocation. My sense is that a lot of user education has to take place as well, teaching people to use opt-in/opt-out technologies with caution.
One of the most exciting features related to HTML5 development is the WebSocket API. Why? Well, WebSockets allow us to have a two-way communication over a TCP socket.
Currently the browser or application has to poll the server each time it wants to update information such as weather, traffic, news, stocks, and so on. With WebSockets, we can reduce this polling dramatically by allowing the server to push data to the browser as it becomes available, rather than constant polling from the browser requesting new data.
For those of you who remember modem terminology from 20 years ago, you’ll be interested to learn that this feature is called “Asynchronous full duplex communication” and adds so much speed and efficiency (some say a reduction as much as 500 to 1) that it would have been hard to imagine back then!
But for Websockets to work requires we break a number of important security rules. First, it takes over Port 80, which is used to screen packets of data for problems. In a Websockets transaction, the headers normally used for screening are not traditional; therefore suspicious or malicious data can pass undetected. Second, reputation-based defenses are disabled by Websockets.
A number of protections are on the way, including solutions from a variety of vendors that do “deep packet” detection and can study with far more efficiency than current techniques data packets being sent via Websockets.
Having a Security Strategy
At this point in the evolution of HTML5, companies looking into application development using it and related APIs must consider a security strategy appropriate for the various layers of your application.
Tending toward the conservative when it comes to finance, privacy, and location data is always a good route for companies to take. If you plan to use any of the technologies described in this article, managers, developers, and security specialists must work together to determine at what layers of the site or application such features may or may not be used.
At the most conservative end of the spectrum, we find security specialists blacklisting all of these techniques described in this article, from file uploads to storage on through to the four primary problem areas. Is that necessary? If you’re in high finance, intelligence, or other highly confidential industries, at this point I have to agree.
But for developers creating apps for fun, or for pragmatic uses such as location-based services or data research, the security concerns can either be addressed if developers are careful, or the issues can reduced by using features only when necessary to enhance and strengthen the user experience of your sites and applications.