eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The war on the words between Apple and Adobe Systems has prompted plenty of speculation about the fate of HTML5. But while HTML5 remains a work in progress, the one thing that is certain is developers who adopt HTML5 will have a new set of features to consider as part of the application security development life cycle.
So how will HTML5 impact the attack surface you have to cover? eWEEK spoke to some security experts and got feedback on a few key areas.
Client-side storage
Earlier versions of HTML only allow sites to store cookies as local information, and these are relatively small and only useful for storing simple profile information or identifiers for data stored elsewhere, such as a session ID, explained Dan Cornell, head of application security research at the Denim Group. HTML5 LocalStorage, however, allows much greater amounts of data to be stored locally by the browser, permitting new types of applications.
“The risk associated with this is that sensitive data may be stored locally on a user’s workstation and an attacker with physical access to that workstation or that compromises the workstation could get access to that data,” Cornell said. “This could be especially bad for users using shared computers.”
“By definition it’s really just the specification of being able to store information on the client system,” Josh Abraham, security researcher for Rapid7, told eWEEK. “So that potentially you have the ability to do client-side-based SQL injection, or you could even have a client whose database is just malicious, and when they synchronize with the production system you have either synchronization issues or potentially malicious data from a client’s database that’s going to be inserted into a production system.”
To address this, developers need to be able to verify whether the data is good or malicious, something which can be a complex question, Abraham said.
Not everyone is in agreement as to how important an issue this is. Veracode CTO Chris Wysopal noted for example that there have always been ways for Web applications to store data client-side through the use of plug-ins or browser extensions.
“There are known methods [of manipulating] the HTML5 SessionStorage attribute as it’s currently implemented, but chances are that this will be fixed by the time the standard is final,” Wysopal said.
Cross-domain communication
While other versions of HTML would only allow JavaScript to make XML HTTP request calls back to the original server, HTML5 has relaxed this restriction so that XML HTTP requests can be made to any server that allows them. This of course poses a security risk if the server is untrusted.
“For example, I could be building a mashup that pulls in sports scores from a third-party site via JSON [JavaScript Object Notation],” Cornell said. “This site could potentially send malicious data back to my application that could run in my users’ browsers. As with many aspects of HTML5, this allows for new types of applications to be built, but if developers start using these capabilities without understanding the security implications they may build applications that open their users up to security risks.”
It’s important that developers writing applications that rely on PostMessage() carefully check to ensure that messages originate from their own sites, because otherwise malicious code from other sites could spoof rogue messages, Wysopal added. The functionality itself, however, isn’t inherently insecure, and developers have used various DOM (Document Object Model)/browser capabilities to emulate cross-domain messaging for some time now, he said.
A related issue is that the World Wide Web Consortium’s current draft for cross-origin resource sharing provides a way to circumvent the same-origin policy using a mechanism similar to the cross-domain, Wysopal continued.
“Even more confusing, IE [Internet Explorer] implements the feature differently from Firefox, Chrome and Safari,” he noted. “Developers need to be sure they understand the dangers of creating an overly permissive access control list, particularly since some of the available documentation on the topic contains reference code that is blatantly insecure.”
Iframe security
There is good news about HTML5 from a security perspective, such as plans to support a sandbox attribute for iframes.
“This attribute will allow a developer to choose how data should be interpreted,” Wysopal said. “Unfortunately, this design, like much of HTML, has a pretty high chance of being misunderstood by developers and may easily be disabled for the sake of convenience. If done properly, it could help protect against malicious third-party ads or anywhere else that accepts untrusted content to be redisplayed.”