Beware Of HTML5 Development Risks

As HTML5 continues to experience a groundswell of acceptance within the developer community, organizations must think seriously about how key changes in this latest standard will require them to shift their application security paradigms for Web and mobile apps. Designed to help developers more closely mimic native application through browser-based apps, HTML5 includes a number of useful features that pose as double-edged swords from a security perspective.

"It provides a slew of new programming methods to websites that could present new security challenges and privacy risks to end users and site operators alike," says Aaron Rhodes, senior security consultant for Neohapsis, a mobile and cloud security services firm.

None of these is as potentially useful -- and damaging -- as the standard's enhanced capabilities for storing and manipulating data on the client, most experts agree.

"At the end of the day, one of the biggest changes is the change of functionality that HTML5 brings, which is its all pushed to the client. That's one of the beauties and also one of the dangers of HTML5," says Steve Orrin, director of security architecture at Intel. "It's a significant paradigm shift, especially in cases where the native applications are phone- or tablet-based, where it doesn't have the conventions of a browser and it has access to native resources."

Local storage is a big change from HTML of the past, where browsers could only use cookies to store small bits of information, such as session tokens, for managing identity.

[How have attackers managed to 'break' AV with a glut of malware? See 10 Ways Attackers Automate Malware Production.]

"HTML5 changes this with sessionStorage, localStorage, and client-side databases to allow developers to store vast amounts of data in the browser that is all accessible from JavaScript," says Dan Kuykendall, CTO of Web application firm NTO OBECTives, who explains that while this provides the opportunity for feature-rich applications and greater offline capabilities, it also opens up a new field of opportunity to attackers. "An attacker could retrieve this data or manipulate the data, which would then get used again later by the application and may be uploaded back to the server to attack others, as well."

As a result, developers have to design with the dangers in mind and weigh that against the type and sensitivity of data stored in the client. At the moment, many development shops are not training their staffs to do that, says David Eads, founder of Mobile Strategy Partners, a mobile development firm that specializes in financial and insurance applications. In fact, he recently ran into a bank that used example HTML5 code for training developers that put data in permanent storage on the client system as opposed to temporary storage.

"There are security issues with even leaving it on temporary storage, but putting it in permanent storage is a bad, bad, bad idea," he says. "And because it is their example, some young developer at the bank is liable to do it that way because he is just typing what he saw."

Storage on the client isn't the only added security consideration brought to bear by HTML5 APIs. They also add additional access to on-device features with huge privacy considerations.

"Another area of concern is rights-based access to system services, such as camera, microphone, and GPS," says Dan Shappir, CTO of Ericom Software, a remote access software developer that has embraced HTML5. "It is highly likely that many users will grant access to such services without considering the security and privacy implications."

Additionally, HTML5 also opens up the field for potential vulnerabilities in third-party code.

"Until HTML5, JavaScript has been limited to requesting resources from the domain from which it was loaded," Kuykendall says. "With the addition of cross-origin resource sharing (CORS), this has been changed to allow JavaScript to request resources from different domains."

It's a useful feature when used in conjunction with strict policies, says Kuykendall, but it could pose problems without. He recommends that developers never use wildcards in Access-Control-Allow-Origin, lest they open themselves up to attacks like clickjacking.

Organizations should generally beware of third-party code when using HTML5 due to the permissions generally allowed on the client, says Brad Carleton, founder and CTO of TechPines, an app development firm.

"Take extra precaution when running code from third parties because they will also have access to whatever permissions have been granted to your application," he says. "This is compounded when you are dealing with multiple third parties because as they are compromised, so can your users."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.