The European Union’s computer security agency is warning that standards under development as part of HTML5 are undergoing rewrites that may neglect important security issues.
The European Network and Information Security Agency (ENISA) released on Monday a 61-page document analyzing HTML5, the latest specification for the Web’s coding mother tongue.
HTML5 is curated by the World Wide Web Consortium (W3C). The organization is accepting comments on the latest draft of HTML5 until Tuesday, and ENISA finished its recommendations just a day ahead of the deadline.
“I think this is special in that it’s the first time anyone has look at those suites of specifications together from a security point of view,” said Giles Hogben, program manager for secure services at ENISA.
The HTML5 specifications are important, as application designers and Web developers will use them as a guide for years to come. The HTML4 specifications, for example, have been in use since 1999.
If the specifications for Web browsers are not up to snuff, it puts everyone from consumers to enterprise users at risk.
“Everybody is using a browser for everything these days,” Hogben said. “It’s really crucial.”
ENISA look at 13 specifications within HTML5 and found 51 security issues. Some of the issues can be fixed by tweaking the specifications, while others are more risks based on the features that users should be alerted to, Hogben said. One of the features that concerns ENISA in the paper is termed “form tampering.”
The HTML5 specification allows for the “submit” button for a Web-based form to be placed anywhere on a Web page. It means it would be possible for an attacker to inject other HTML onto the page, such as a different form button, and then cause the information in the form to be sent to the attacker rather than the legitimate website.
The new functionality “has benefits for developers,” Hogben said. “We are not suggesting that W3C should take that feature out, it’s just that users should be aware of the risks that it creates.”
ENISA also made recommendations for how browsers should behave when a user, for example, is doing an online banking transaction. Users should use different browsers or at least have sandboxed sessions when using multiple tabs. A sandboxed browser session would avoid another tab — which could contain an attack page — take advantage of loose settings or permissions set for the whole browser application.