

HTML 5 features present new security risks

Find out why new HTML 5 features are going to represent a new opportunity for malware writers.

Will new HTML 5 features provide opportunities for malware writers, as some AV companies predict? Why or why not?
Practically every technology provides opportunities for malware writers, and with the number of new HTML 5 features, there are bound to be plenty of opportunities. Even if HTML 5 were designed with integrated security, there would still be attempted attacks, as any new technology is attacked and investigated for security weaknesses and vulnerabilities. HTML 5 is going to be complex and support a wide variety of functions that are currently handled by multiple different plug-ins. This sort of broad functionality, in general, tends to raise the potential for attacks; the more code there is, the more complex and potential weaknesses there are for attackers to exploit.

One of the new high-risk HTML 5 features is the cross-domain trust functionality. The cross-domain trust functionality...

will allow different domains (DNS names) to communicate between iframes in your Web browser. This feature will be tricky for developers to get right initially -- need to verify that the cross-domain requests are received from other domains from domains from which they expect to receive requests -- and even advanced, technical users may find it difficult to understand the risks involved. Malware writers will likely try to abuse this functionality to gain access to sensitive data, since this check may not happen as intended.

One of the most difficult security issues with HTML 5 is the movement of functionality from the server to the client where the server may trust the client perhaps more than it should. One example is the server trusting that the data from a client contains valid, non-malicious input. The server would assume the client is checking for these types of attacks/bugs on his or her own, so there would be a disconnect there. Servers and applications should be programmed to validate data received from the client to ensure it is not malicious.

This was last published in May 2010

Dig Deeper on Web application and API security best practices