Risk

6/19/2013
12:48 AM
Connect Directly
Twitter
Twitter
RSS
E-Mail
50%
50%

Beware Of HTML5 Development Risks

Local storage, native resource rights, and third-party code all add greater functionality and higher risk to HTML5 applications

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. Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
13 Russians Indicted for Massive Operation to Sway US Election
Kelly Sheridan, Associate Editor, Dark Reading,  2/16/2018
Facebook Aims to Make Security More Social
Kelly Sheridan, Associate Editor, Dark Reading,  2/20/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
How to Cope with the IT Security Skills Shortage
Most enterprises don't have all the in-house skills they need to meet the rising threat from online attackers. Here are some tips on ways to beat the shortage.
Flash Poll
[Strategic Security Report] Navigating the Threat Intelligence Maze
[Strategic Security Report] Navigating the Threat Intelligence Maze
Most enterprises are using threat intel services, but many are still figuring out how to use the data they're collecting. In this Dark Reading survey we give you a look at what they're doing today - and where they hope to go.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.