Features/Platform/Iframe Sandbox: Difference between revisions

Features/Platform/Iframe Sandbox (view source)

Revision as of 21:41, 4 March 2012

5 bytes added , 4 March 2012

no edit summary

Imelven

Confirmed users

197

edits

@@ Line 16: / Line 16: @@
 |Feature open issues and risks=* The origin (in string form) of a null principal - this will be sent by CORS, the origin header (if/when it's implemented), postMessage etc - the HTML5 spec says that it should be a GUID in this case - need to see what gets used in these cases when content has a null principal a
 * what to do with Workers in a sandboxed frame - would probably need allow-scripts for these, and maybe allow-same-origin ? or just block them altogether, as apparently some other browsers have done
 * are there other methods that the ones mentioned in the HTML5 spec (target='blank_', showModalDialog() and window.open) to open new windows ?
 |Feature overview=The HTML5 standard specifies a new attribute for the IFRAME element, "sandbox". See also [https://bugzilla.mozilla.org/show_bug.cgi?id=341604 bug 341604] "Implement HTML5 sandbox attribute for IFRAMEs" and [https://bugzilla.mozilla.org/show_bug.cgi?id=671389 bug 671389] "Implement CSP sandbox directive"
 |Feature users and use cases=Users are web developers looking for a way to isolate content on their site and preventing it from having its default same origin privileges and ability to execute scripts. The HTML5 spec specifies some modifying attributes that can re-grant permissions such as same origin privilege, executing scripts, navigating the top window and submitting forms, etc.
@@ Line 27: / Line 27: @@
 * implementing @sandbox on <frame> - this was discussed on the whatwg list and @sandbox for <frame> will not be implemented at the current time (this matches at least one other implementation)
 * implementing @sandbox on <xul:iframe/browser/editor> - the current implementation shouldn't prevent this enhancement from being implemented but there are no plans to implement this at the current time
+|Feature functional spec=An IFRAME with the sandbox attribute (and its various modifying attributes) should behave as outlined in the HTML5 spec. See W3C Working Draft at http://www.w3.org/TR/html5/the-iframe-element.html#the-iframe-element and W3C Editor's Draft at http://dev.w3.org/html5/spec/Overview.html#the-iframe-element. This feature attempts to be compatible with the CSP sandbox directive (see https://wiki.mozilla.org/Security/CSP/Sandbox) by establishing infrastructure where CSP would only have to set the sandbox flags on content documents to have them sandboxed as intended.
-|Feature functional spec=An IFRAME with the sandbox attribute (and its various modifying attributes) should behave as outlined in the HTML5 spec. See W3C Working Draft at http://www.w3.org/TR/html5/the-iframe-element.html#the-iframe-element and W3C Editor's Draft at http://dev.w3.org/html5/spec/Overview.html#the-iframe-element. This feature attempts to be compatible with the CSP sandbox directive (see https://wiki.mozilla.org/Security/CSP/Sandbox) by establishing infrastructure where CSP would only have to set the sandbox flags on content documents to have them sandboxed as intended.
 |Feature implementation plan=* The general approach is to give a sandboxed IFRAME a null principal to remove its normal domain/principal. This removes its same origin privileges (unless allow-same-origin is specified as part of the sandbox attribute)
 * We will use nsDocShell::SetAllowJavascript(false) to prevent scripts being executed (unless allow-scripts is specified as part of the sandbox attribute)
@@ Line 35: / Line 34: @@
 nsIDocShell.idl will contain :
+<pre>
 +  /**
 +   * This flag prevents content from navigating browsing contexts other than
@@ Line 74: / Line 73: @@
 +   */
 +  const unsigned long SANDBOXED_SCRIPTS = 0x20;
+</pre>
 ** when the sandbox attribute on an IFRAME element is modified, we will change the flags on the docshell but not the document
 *** we will implement this using nsGenericHTMLFrameElement::AfterSetAttr,
@@ Line 90: / Line 89: @@
 * for CSP sandbox, the flags will only be stored on the document itself - when content is navigated to, the CSP sandbox flags won't be persisted (unless the new content also specifies a CSP sandbox directive)
 * the HTML5 spec provides examples of how to apply flags with nested IFRAMEs, abarth has proposed that if both CSP and IFRAME sandbox can apply to content, the algorithm used in these example should be used to merge the policies which sounds reasonable
 |Feature security review=This feature will definitely need a full security review from the secteam. I suggest discussing the spec and making sure other means to do actions like opening windows or 'doing something automatically' are also covered by the implementation and test suite.
 |Feature qa review=We will need a test suite for this feature. Microsoft has released test cases for sandboxing publically that have been submitted to the W3C for inclusion in the HTML5 test suite. We will definitely want to compare our implementation to other browsers' implementation for consistency etc. and address inconsistencies via suggested modifications to the HTML5 spec and discussion on the whatwg list. Boris Zbarsky has suggested submitting our sandbox test suite to the W3C also.
 A mochitest test suite will be written to provide consistent automated testing for this feature.
 |Feature implementation notes=See https://bugzilla.mozilla.org/show_bug.cgi?id=341604 for a patch that attempts to implement HTML5 iframe sandbox. tests will be posted in that bug as well when complete.
 |Feature landing criteria=* Needs a test suite
 * Needs to be compared against other implementations and public test suites for consistency