Despite being installed on nearly every Internet-connected computer, it looks like Flash, Adobe's long-troubled...
format for Web multimedia, will soon be replaced by the upcoming standard HTML5. In Adobe's own words, "HTML5 is now universally supported on major mobile devices, in some cases exclusively. This makes HTML5 the best solution for creating and deploying content in the browser across mobile platforms."
This is surely sad news for enterprise attackers. In recent years, Flash has been a popular target for malicious hackers. According to security research firm WhiteHat Security Inc., Flash Player-related vulnerabilities accounted for approximately 14% of all the Web application vulnerabilities they discovered.
So is the demise of Flash good news for security? Will HTML5 replace Flash, and if so, how does HTML5 security stack up against Flash? And how should security pros prepare for the rollout of HTML5 Web content? That's what we'll discuss in this tip.
HTML5 enjoys the support of the Internet's biggest players, including Facebook, Google and PayPal. In fact, it’s on course to becoming the future standard for Internet video and should supplant non-standard formats, such as Flash and Microsoft's Silverlight. Flash is a binary format for multimedia content using the object-oriented development language ActionScript and requires an Adobe plug-in. HTML5, on the other hand, is an open source markup language that does not require a plug-in to run its applications. Removing the need for proprietary plug-ins in order to play video certainly closes a common attack vector, and because HTML5 updates are delivered through browser updates, they're far more likely to be applied than patches for plug-ins. However, HTML5 provides far more access to a computer's resources, including local data storage, which potentially opens up new opportunities for cybercriminals.
My main concern with HTML5 is that developers will rush to incorporate it into enterprise websites without taking the time to fully understand its new features and how to securely implement them. As an example, cross-origin resource sharing (CORS) permits a Web server to allow its resources to be accessed by a webpage from a different domain. CORS relaxes the Same Origin Rule, which is one of the fundamental security controls built into Web browsers. Unless developers know how CORS works, they can easily make erroneous assumptions and allow attackers access to content that should not be shared. The same holds true for HTML5 cross-document messaging. It is secure when properly used, but if developers don’t check to ensure that messages originate from their own sites, malicious code from other sites can spoof rogue messages. It’s a basic security tenet that data from the browser should be considered untrusted and therefore must be validated. Current validation processes and filters should be reviewed during the Web application development process as new HTML5 elements and attributes may cause unexpected results. Whitelisting-based filters built into the applications should prove more resilient.
Security weaknesses can appear in any technology when developers use it for reasons other than those for which it was originally intended. For example, the HTML5 Web Storage specification provides developers with a more flexible alternative to cookies for storing data in the browser. Of course, there is the risk it’s used to store sensitive user data that could be compromised by a cross-site scripting (XSS) attack, but sites are already using it to store scripts so pages load faster. Consider this example: In order to save time and bandwidth, the former Web service Apture used a localStorage object to cache its application-logic code, but a page on the same domain as those scripts had a reflected XSS vulnerability, which could be used to inject malicious code in the cache. The malicious code turned the vulnerability into a persistent, client-side XSS attack across all domains using the Apture service. Pulling data or scripts from third-party sources creates an implicit trust relationship. Developers must be aware of the potential risks and understand how to sanitize this content before including it in their own sites.
Security teams will need to assess the use of the WebSocket API, which replaces the need for a browser to poll a Web server for the latest data. The server only pushes information out when it is new, which reduces unnecessary traffic between server and browser. However, WebSocket thwarts a number of important network security controls, including traditional packet headers used by firewalls to block suspicious traffic. Reputation-based defenses are also less effective. This increases the need for a firewall with deep content inspection that can handle data flowing through a WebSocket to be able to assess the content, structure and intent of the traffic. Again, whitelisting will prove to be more effective.
The HTML5 standards bodies, as well as browser vendors, have thoroughly thought about how best to eradicate certain security and privacy issues. However, HTML5 is still evolving as a standard and is certainly not a multimedia Web development security cure-all for developers that lack the wherewithal to code securely. Even for those developers that do code securely, phishing, malware and denial-of-service attacks will still exist. Replacing your site’s applications and code with HTML5 is a big undertaking and things will invariably break. Restore processes should be tested thoroughly prior to work commencing and critical functions should initially be run in parallel. To provide additional protection against various attacks, I recommend moving the site to HTTPS only as part of any upgrade.
Penetration tests must accompany any HTML5 development effort, and should include the sophisticated presentation layers that can be created using HTML5 to ensure they are performing as intended. Attackers will certainly test browser vendors’ implementations of new functionalities and data formats, such as <canvas>, <video> and their attributes for coding errors that may allow buffer overflows and other attacks. This means security teams and developers need to remain aware of vendor updates to ensure patches and mitigating security controls can be put in place sooner rather than later.
HTML5 means developers can now incorporate multimedia into their sites using an open standard. This is a far better situation than using an assortment of third-party plug-ins. As long as developers take the time to learn how to use its many new features securely, the security industry can look forward to a richer and more secure Internet. However, history shows that this is unlikely, so the need for robust perimeter defenses and pen tests is not going to disappear any time soon.
About the author:
Michael Cobb, CISSP-ISSAP, is a renowned security author with more than 15 years of experience in the IT industry and another 16 years of experience in finance. He is the founder and managing director of Cobweb Applications Ltd., a consultancy that helps companies to secure their networks and websites, and also helps them achieve ISO 27001 certification. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. Michael is also a Microsoft Certified Database Administrator and a Microsoft Certified Professional.