In a recent and excellent post, Paul Roberts from ThreatPost explored the security of HTML 5, the upcoming version of the markup language that fuels the Web.

The post provides an overview of the major security features of the new specification. It also conveys the concerns security experts have with what will probably be the vector of a new Web revolution.

Quoting Adam Barth of the University of California, Berkeley, Paul Roberts writes:

HTML5 actually specifies how HTML code should be parsed by Web browsers. Previous iterations of the language left it up to individual platform vendors to develop their own interpretations of how the code should be parsed, which led to differences in how the language was rendered on different browsers. That also created opportunities for attackers to exploit quirks in the HTML parsing of specific browsers in Cross Site Scripting and other Web based attacks…

While this might be considered good news, given the current difference in HTML 4 implementation among browsers, I am bothered with the use of should instead of must in the sentence above. At any rate, I don’t see how HTML 5 would enforce similarity in parsing. Would a website refuses to display an HTML 5 page unless the browser which made the request is on a list of 100% compliant browsers?

Let’s assume that HTML 5 can tell browsers how they must parse it. Will we end up with a class break across all HTML 5 ready browsers shall the specification suffer from a vulnerability that affects its design?

Further down, still quoting Adam Barth, Paul Roberts writes:

New features are also intended to make HTML5 more secure than its predecessors. Among them is a new sandbox attribute that allows Web sites that use iFrames to aggregate untrusted content from external sources to run it in a secured environment. The postMessage() feature, for cross document messaging, allows secure communication between different web sites in the browser…

This sounds like a major security feature in HTML 5. The ability of controlling external input while serving it to the browser looks like a good way to thwart the problems we currently have with mash-ups and similar content aggregation techniques. However, problems have already been found with the technique:

The new sandboxing and postMessage() features are examples of tools that, if not used properly, could fail to provide protection against hacks, or even enable new types of attacks. Veracode, in its analysis of HTML5,  raised red flags about the security of the postMessage() feature, as well, noting that Web applications that use cross-document messaging could be vulnerable to attack from malicious Web sites, which could spoof rogue messages.

Among other concerns:

“HTML5 has an enormous amount of functionality. The (specification) is just huge,” said Jeremiah Grossman of Web security firm WhiteHat. The breadth of the new specification gives him concern. “I know that we’re still finding vulnerabilities in HTML4,” Grossman said.

And:

“With any new functionality you’re going to have new security concerns. HTML5 is going to increase the attack surface considerably,” said Neil Daswani of Web security firm Dasient.

So HTML 5 is a huge specification that offers a huge attack surface. Are we calling for disaster here? I hope that the persons who are involved in its development have more that functionality in their minds and agendas.

Moreover:

HTML5’s ability to support native rendering of audio and video files could allow attackers to take advantage of security vulnerabilities in supported audio and video file formats for Web based attacks…

During CanSecWest 2008, Thierry Zoller and Sergio Alvarez from the now-defunct n.runs company demonstrated many ways to exploit parsing bugs in anti-virus software to circumvent them or exploit them to get a foothold on the systems on which they run. This is due to their support of many, different file formats. I guess you see know what I am aiming at. Need another example? Wireshark, the ubiquitous network sniffing software, has suffered from many vulnerabilities due to parsing bugs in its implementation of a wide array of protocols. I clearly don’t see why HTML 5 wouldn’t suffer from the same types of mistakes.

One other area of concern is HTML 5 support for event handlers:

HTML5’s broader support of event handlers on HTML elements could defeat blacklist filters designed to allow HTML but block scripting.

And while this major revision of HTML is still under development, sites such as YouTube are already adopting it:

Grossman said he sees support for HTML5 in around 10% to 12% of the 2,000 Web sites his firm monitors. It could be three years or more before the security implications of the new capabilities in HTML5 are fully grasped, he said.