It has been a long time coming, but HTML5 is all but upon us now. And the new HTML5 browsers promise a more sophisticated, richer browsing experience without resorting to plug-ins. But what does HTML5 do to the security of the browser? Is HTML5 a security risk? For the most part, the answer is "no more than any other browser," but there are some interesting exceptions that largely rely on web developers to do the right things.
It's important to remember that pre-HTML5 browser have security risks also. These would include such issues as <base> link hijacking and exploitation of <object> data URLs. These are security risks that have persisted for some time but for the most part haven't been exploited significantly, nor fixed.
There are some concerns that new tags like <video>, <audio>, and <canvas> increase the surface attack area of HTML5-capable browsers, but those risks lie in the hands of the developers of the browsers. The real risk comes down to web developers themselves, misusing some new features.
The largest area of concern for me is the new Cross-Origin Resource Sharing (CORS) feature. The idea of CORS is a good one, providing a legitimate means for developers to overcome the same origin policy (SOP). SOP is an old policy, dating back to the early days of Netscape Navigator. The core of the policy says that URLs in JavaScript (and elsewhere) can only refer to the origin URL of the page—so if you're on example.com, you can only call code from example.com in JavaScript. SOP is a good web browsing safety mechanism; it allows the user to know what website they are trusting. But it has limitations.
But SOP impairs things like mashups, pulling data and features from two different websites onto one page. There are workarounds for SOP, but nothing official, until CORS. With CORS, web developers are able to specify in the HTTP header additional origin URLs. So in a mashup, the URLs of both sites would be listed as origins, allowing the mashup to operate without fancy tricks.
A lazy developer could specify a CORS origin header that allows any URL to be origin, thereby enabling unlimited cross-site scripting.
Combining this behavior with the new local storage features of HTML5 could get really ugly. That same lazy developer could be stuffing a security token in local storage, which with cross-site scripting would now effectively be available to any chunk of JavaScript running on any site that was referenced in the web page, all without warning the user.
That combination could lead to serious security violations, but notice that it takes a series of bad choices by a developer to get there. Which brings up the real point of browser-based security: It is up to the web developer to be secure. HTML5 can be used for good or evil, but apathy to its rules will lead to serious consequences. Be safe out there.
Richard Campbell ([email protected]) is a cofounder of Strangeloop Networks. He has more than 30 years of high-tech experience and is both a Microsoft Regional Director and Microsoft MVP. In addition to speaking at conferences around the world, Richard is co-host of .NET Rocks! (www.dotnetrocks.com) and host of RunAs Radio (www.runasradio.com).
