Features/Platform/Iframe Sandbox: Difference between revisions

Features/Platform/Iframe Sandbox (view source)

Revision as of 00:01, 4 November 2011

128 bytes added , 4 November 2011

no edit summary

Imelven

Confirmed users

197

edits

@@ Line 18: / Line 18: @@
 * Blocking form submission - what's the right way to do this ?
 * 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
 |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. The HTML5 spec specifies some modifying attributes that can re-grant permissions such as executing scripts and submitting forms, etc.
@@ Line 28: / Line 26: @@
 * We will use nsDocShell::SetAllowJavascript(false) to prevent scripts being executed (unless allow-scripts is specified as part of the sandbox attribute)
 * We will use nsDocShell::SetAllowPlugins(false) to prevent plugins being loaded by a sandboxed IFRAME
-* We will create the flags as described in the HTML5 spec's description of the IFRAME sandbox attribute on both the docshell and the document when it is loaded - this is necessary due to the spec'd behavior of when dynamically modifying sandbox attributes actually takes effect (changing sandboxed attributes does NOT affect an already loaded document's restrictions)
+* We will create the flags as described in the HTML5 spec's description of the IFRAME sandbox attribute on both the docshell and the document when it is loaded
 ** when the sandbox attribute on an IFRAME element is modified, we will change the flags on the docshell but not the document
+** the document needs to keep the exact set of flags assigned at load time (these are immutable - changing sandbox attributes does NOT dynamically affect already loaded content)
+** sandbox flags for a document are set based on the sandbox flags of its parent document and the sandbox flags of the embedding frame (stored in the docshell)
 * nsFrameLoader will be modified to assign the null principal to a sandboxed IFRAME (if allow-same-origin is not specified)
 ** this also requires modifying surrounding code to be able to force an owner to be set on the loading channel.
 ** SHentry will also need the same 'force owner' flag for when the IFRAME is loaded from session history.
 ** The nsFrameLoader will check if its owner content has the sandbox attribute set and is an nsHTMLIFrameElement to determine whether to sandbox the frame being loaded (again, if the allow-same-domain modifier isn't present in the sandbox attribute)
 * when we support  the CSP sandbox directive, similar logic to that in nsFrameLoader will need to be implemented for the loaders for other CSP-protectable resources
 |Feature security review=This feature will likely need a full security review from the secteam.
 |Feature qa review=We will need a test suite for this feature. Microsoft has released test cases for sandboxing, I'm not sure of their licensing status currently. We will definitely want to compare our implementation to other browsers' implementation for consistency etc. and likely address inconsistencies via suggested modifications to the HTML5 spec.