Risk
6/19/2013
00: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
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-4734
Published: 2014-07-21
Cross-site scripting (XSS) vulnerability in e107_admin/db.php in e107 2.0 alpha2 and earlier allows remote attackers to inject arbitrary web script or HTML via the type parameter.

CVE-2014-4960
Published: 2014-07-21
Multiple SQL injection vulnerabilities in models\gallery.php in Youtube Gallery (com_youtubegallery) component 4.x through 4.1.7, and possibly 3.x, for Joomla! allow remote attackers to execute arbitrary SQL commands via the (1) listid or (2) themeid parameter to index.php.

CVE-2014-5016
Published: 2014-07-21
Multiple cross-site scripting (XSS) vulnerabilities in LimeSurvey 2.05+ Build 140618 allow remote attackers to inject arbitrary web script or HTML via (1) the pid attribute to the getAttribute_json function to application/controllers/admin/participantsaction.php in CPDB, (2) the sa parameter to appl...

CVE-2014-5017
Published: 2014-07-21
SQL injection vulnerability in CPDB in application/controllers/admin/participantsaction.php in LimeSurvey 2.05+ Build 140618 allows remote attackers to execute arbitrary SQL commands via the sidx parameter in a JSON request to admin/participants/sa/getParticipants_json, related to a search parameter...

CVE-2014-5018
Published: 2014-07-21
Incomplete blacklist vulnerability in the autoEscape function in common_helper.php in LimeSurvey 2.05+ Build 140618 allows remote attackers to conduct cross-site scripting (XSS) attacks via the GBK charset in the loadname parameter to index.php, related to the survey resume.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Where do information security startups come from? More important, how can I tell a good one from a flash in the pan? Learn how to separate ITSec wheat from chaff in this episode.