Since the release of HTML 5 standard is expected in 2011, it is important to prepare for the potential impacts on security due the adoption of HTML 5. Currently, we can review the working draft from W3C and start looking at this standard from the secure coding perspective and specifically on how to write secure HTML 5 software. Since this blog is dedicated to software security, I thought I should try to put out a list of top security concerns that need to be addressed when coding applications in HTML 5. Herein included is my top 7 list of software security best practices that need to be addressed when coding HTML 5 applications:
1) Be careful when using cross domain messaging features
HTML 5 APIs allow to process messages from an origin that is different from the one of the application processing the message. You should check the origin of the domain of the message to validate that can be trusted such as by whitelisting the domain (accept only request from trusted domains and rejects the others). Specifically, when using HTML 5.0 APIs such as PostMessage(), check the dom-MessageEvent-origin attribute before accepting the request.
2) Always validate input and filter malicious input before using HTML 5.0 APIs.
You should validate data input before you process any messages of HTML 5.0 APIs such as the PostMessage() API. Input validation should be done at a minimum, on the server side since client side validation can be potentially bypassed with a web proxy. . If you are using client side SQL such as WebSQL (like Google gears for example) you should filter data for any SQL injection attack vectors and use prepared SQL statements.
3) Make sure that the use of any offline-local storage is secure
Whenever possible, do not store any confidential or sensitive data in the offline-local storage, if you do, make sure you encrypt the data. If you do encrypt the data in the offline-local storage, do not store any encryption keys on the client rather, use the server to encrypt this data on demand. Make sure the encryption key is tied to the user's session and to the device that is storing it. Beware that HTML 5 offline applications are vulnerable to cache and cache poisoning hence validate the data before putting anything in offline/local storage. If should also consider to restrict the use of offline/local storage as requirement of your HTML 5.0 security coding standards is possible. Consider that right now (Jan 2011), offline-local storage is not supported by IE browsers, only by Google Chrome, Safari, Firefox and the beta of the Opera browsers.
4) Secure code review HTML 5 code and the coding of HTML 5 tags, attributes and CSS.
You should update your secure code analysis rules to include security checks for special HTML coding attributes and HTML 5.0 tags. Some of HTML 5 tags attributes for example can be potentially be injected JavaScript (JS). You should made a requirement to source code review these new HTML 5 tags for security to make sure any JS input is validated. A new version of HTML 5 CSS also might allow an attacker to control display elements via JS injection. HTML 5 source code with tags, attributes and HTML 5 CSS files should be considered in scope for source code reviews before deployment.
5) Consider to restrict or ban the use of HTLM 5.0 websocket API.
HTML 5.0 websocket API provide a network communication stack to the browser that can be used for backdoors. You should check with your security team whether the use of web sockets is allowed by your organization information security policies and application security standards.
6) Make sure your company legal approve any use of geolocation API.
Consider the impact of privacy when using geolocation APIs to make sure the use is allowed and compliant by your company legal-privacy laws/regulations. The use of geolocation might have privacy impacts, hence should be reviewed to be in compliance with privacy policies that might include notify the user when these APIs are deployed as part of your application.
7) Leverage the security of sandboxing iFrame attributes
One of the HTML 5 features is the sandboxing attribute for iFrame that enables a set of extra restrictions on any content hosted by the iFrame. When this is attribute is set, the content is treated as being from a unique origin, forms and scripts are disabled and links are prevented from targeting other browsing contexts and plug-ins are disabled. Ian Hickson, the editor of the HTML 5 has a post on what the sandbox is good for. You should consider updating your organization's secure coding standards to cover how to code securely applications that leverage the HTML 5.0 sandbox attribute for IFrames.
8 comments:
waw... nice info !
Good summary.
While all the tips are good in general, there's a slight inconsistency in the last one. Iframe sandbox not only does not protect you from clickjacking attacks - it facilitates them. Sandboxed iframes cannot by default framebust using Javascript top.location override (the most popular form of framebusting technique).
While using X-Frame-Options header would help, it's
almost never used ( see e.g. http://twitter.com/#!/mniemietz/status/34182195732025345 )
See details of that at http://heideri.ch/jso/#122
It's a not-so-rare case where new security feature breaks up existing defense methods.
Krzysztof you are correct that sandboxing basically disable JS on the frame and renders the frame busting off technique usless. The frame busting off technique is actually not fool proof as there are several ways to break it see http://seclab.stanford.edu/websec/framebusting/framebust.pdf
Nevertheless I thought that that sandbox attribute could control third party content and enforce the single origin policy of the browser whose vulnerability is ultimately is the root cause of cross frame scripting
Actually, sandbox is worse than just disabling JS, which could have several side effects for the framed site. With sandbox="enable-scripts" you can enable JS but disable top.location assignment, and that will alter the framebusting code ONLY.
There are, as you mentioned, a few existing counter JS framebusting techniques, iframe sandbox just tops them all, because it will be the easiest and most elegant one. For example - it does not require a confirmation from user like the onbeforeunload technique.
Sandbox is good against same-domain XSS, phishing attacks and securely including 3rd party code (think - ads), but for clickjacking alone it makes things worse.
I removed the reference to iframe sandboxing for remediation for XFS click-jacking. I agree that HTML 5 sandboxing can render existing XFS countermeasures like frame busting useless, and this should be captured as part of coding standards practice when coding with iframe sandboxing. That being said, I do not believe fixing click-jacking or cross frame scripting vulnerability is HTML 5 task rather should be the browser's vendor task to make browser capable to enforce the SOP (Single Orgin Policy) that is cross frame scripting root cause. As you indicated you can use X-FRAME-OPTIONS, available for IE 8 browser to mitigate clickjacing attacks for Mozilla and other browsers you can use the NoScript plugin.
Post a Comment