Features/Platform/Iframe Sandbox: Difference between revisions

|Feature status=In progress

|Feature health=OK

}}

{{FeatureTeam

* 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

* sandboxed IFRAME's should not be able to create popups, even with the 'allow-scripts' modified specified - need to figure out how to implement this block

|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.

|Feature requirements=If at all possible, this feature should be designed and implemented in a way that makes it usable for also implementing the sandboxing required to support the CSP (Content Security Policy) sandbox value also.

|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 should also be compatible with the CSP sandbox directive (see https://wiki.mozilla.org/Security/CSP/Sandbox)

|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-domain is specified as part of the sandbox attribute)

** 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)

* sandboxed IFRAME's need to block access (read and write) to document.cookie  

and local storage unless the allow-same-domain keyword is specified  

* 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

* 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 likely need a full security review from the secteam.

}}

{{FeatureInfo