ChangeProposals/sandbox allow popups

ISSUE-180: Add “allow-popups” for iframe@sandbox

SUMMARY

Content rendered in a sandboxed iframe is restricted from creating popups (window.open(), showModalDialog(), target=”_blank”, etc.). However, there are legitimate use cases where a host may wish to allow the content to open popup windows. Using a simple inheritance policy for sandboxed flags can enable such functionality (when granted by the hosting document) safely.

Internet Explorer 10 implements the sandbox keyoward “ms-allow-popups” as a way for the hosting (trusted) document to allow the sandboxed content to open popup windows. Those popup windows inherit the same sandbox flags as the original sandboxed content.

Webkit is in the process of implementing similar functionality 1 . This change proposal is to add this functionality to HTML5.

RATIONALE

There are numerous use cases on the web where content could be considered untrusted (and therefore, a candidate for sandboxing) however that content will not function without the capability of creating new browsing contexts.

As a simple example, consider hosting a maps control in a page. The maps control is hosted from another domain and outside the hosting author’s control. Such a mash-up is a perfect use case for HTML5 Sandbox. However, many of these types of controls include links that are targeted to open in a new browsing context. There is an example of such a scenario at the IE Test Drive site (requires an HTML5 Sandbox supporting browser, such as IE10 Platform Preview 2, Chrome, or Safari). 2

HTML5 Sandbox is primarily focused on protecting trusted content from untrusted content that it hosts. Unprotected popups created by untrusted content could represent an increased attack surface area if they are not sandboxed (e.g., sandboxed untrusted content opens itself as a popup window that isn’t sandboxed). However, if the popup window is also subjected to the same sandbox flags then the security concern is mitigated.

As specified today, HTML5 allows user agents to give users the option to allow untrusted content to create a popup. However, doing so may enable the user to unintentionally violate the protection of the trusted content from the sandboxed content. One simple example of this is as follows:

• Trusted.com sandboxes untrusted.html—served from the same domain.
• Untrusted.html wishes to create a new auxiliary browsing context. The user agent prompts the user to allow and the user complies.
• Untrusted.html creates a new auxiliary browsing context with the active document: untrusted.html.
• Untrusted.html is rendered unsandboxed with access to trusted.com’s storage, etc.

This change proposal would provide a mechanism (the “allow-popups” keyword) for trusted.com to allow untrusted.html to open popup windows. However, those popup windows would inherit the same security restrictions as unstrusted.html therefore mitigating the vulnerability described in the scenario above. If “allow-popups” is not specified, untrusted.html must not be allowed to create a new auxiliary browsing context.

Internet Explorer 10 implements the functionality described by this Change Proposal under a prefixed keyword: “ms-allow-popups”. Adam Barth is working on a patch for Webkit which implements this same behavior. See Appendix A for a real author request for allow-popups for valid scenarios, which they believe “are satisfied by the IE10 allow-popups flag.”

DETAILS

1. Section 4.8.2 – The iframe element
   1. http://dev.w3.org/html5/spec/Overview.html#attr-iframe-sandbox
      1. Add “allow-popups” to the list of allowed values.
      2. Change the last sentence of the first paragraph introducing the sandbox attribute to: “The allow-same-origin keyword allows the content to be treated as being from the same origin instead of forcing it into a unique origin, the allow-top-navigation keyword allows the content to navigate its top-level browsing context, the allow-popups keyword allows the content to create new auxiliary browsing contexts, and the allow-forms and allow-scripts keywords re-enable forms and scripts respectively.”
   2. http://dev.w3.org/html5/spec/Overview.html#sandboxed-navigation-browsing-context-flag
      1. Change the first paragraph to: “This flag prevents content from navigating browsing contexts other than the sandboxed browsing context itself (or browsing contexts further nested inside it), new auxiliary browsing contexts (which are protected by the sandboxed auxiliary navigation browsing context flag flag defined below), and the top-level browsing context (which is protected by the sandboxed top-level navigation browsing context flag defined next).”
      2. Remove the second sentence: “This flag also prevents content from creating new auxiliary browsing contexts, e.g. using the target attribute, the window.open() method, or the showModalDialog() method.”
      3. Add a new sandbox flag: The sandboxed auxiliary navigation browsing context flag , unless the sandbox attribute’s value, when split on spaces, is found to have the allow-popups keyword set This flag prevents content from creating new auxiliary browsing contexts, e.g. using the target attribute, the window.open() method, or the showModalDialog() method.
2. Section 5.1.6 Browsing context names
   1. Update the table:
      1. For sandbox examples, replace “maybe new” with “none”.
      2. Add the following column for allow-popups:

1. 1. http://dev.w3.org/html5/spec/Overview.html#sandboxWindowOpen
      1. Revise the first option for creating a new browsing context to read: “If the current browsing context had the sandboxed navigation browsing context flag set when its active document was created. There must not be a chosen browsing context.”
      2. Before that, add the following as the (new) first option for determining a new browsing context:

         “If the current browsing context had the sandboxed auxiliary navigation browsing context flag set when its active document was created and the user agent has been configured such that in this instance it will create a new browsing context

         A new top-level browsing context must be created. If the given browsing context name is not _blank, then the new top-level browsing context's name must be the given browsing context name (otherwise, it has no name). The chosen browsing context must be this new browsing context.

         For each of the following flags, if it is set on the current browsing context then also set these flags upon creating the active document for the new top-level browsing context:

         • The sandboxed navigation browsing context flag
         • The sandboxed top-level navigation browsing context flag
         • The sandboxed auxiliary navigation browsing context flag
         • The sandboxed plugins browsing context flag
         • The sandboxed seamless iframes flag
         • The sandboxed origin browsing context flag

IMPACT

Positive:

• The current vulnerability present in HTML5 where UAs allow sandboxed content to open unsandboxed popups is mitigated.
• Sandboxed content can safely open popup windows when allowed by their host. Providing this functionality increases the number of scenarios where sandbox can be used effectively.

Negative:

• None known

Risks:

• None known

APPENDIX A

From: Jason Henderson
Sent: Wednesday, August 17, 2011 2:30 PM
To: adam@adambarth.com
Cc: Jacob Rossi
Subject: Supporting allow-popups in Chrome and Webkit

Hi Adam, I’m a Program Manager in the Office organization at Microsoft. We are using the HTML5 sandbox iframe attribute and are finding the support of pop-ups very important for a couple core scenarios. We have several Web App scenarios where sandboxed code needs to be able to pop-out windows/forms from the host app, as well as certain authentication scenarios where sandboxed code needs to be able to pop-out an authentication window so the URL can be validated by the end user before credentials are entered, as well as scenarios where the sandboxed code needs to be able to have more real-estate than we give it by default in the iframe and so pop-ups are needed to allow it to display more content.

We believe all of these scenarios are satisfied by the IE10 allow-popups flag and we would like to see support added in Chrome/Webkit for this as well. Currently we are having to implement two codepaths one for IE10/browsers without sandbox support and one for Chrome and other WebKit browsers that is a suboptimal user experience. Please let me know if you have any questions – but I just wanted to make sure you had our input on the importance of getting this into Chrome and Webkit.

Thanks,
Jason