Application security pros say HTML5 brings with it a new set of security concerns for developers.
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."
Print
