Confirmed users
197
edits
Features/Platform/Iframe Sandbox: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 4: | Line 4: | ||
|Feature status=In progress | |Feature status=In progress | ||
|Feature health=OK | |Feature health=OK | ||
|Feature status note=initial implementation done, initial test suite | |Feature status note=initial implementation done, initial test suite done, working through some hopefully final design decisions | ||
}} | }} | ||
{{FeatureTeam | {{FeatureTeam | ||
| Line 14: | Line 14: | ||
}} | }} | ||
{{FeaturePageBody | {{FeaturePageBody | ||
|Feature open issues and risks= | |Feature open issues and risks= | ||
|Feature overview=The HTML5 spec specifies a new attribute for the IFRAME element, "sandbox", see http://dev.w3.org/html5/spec/the-iframe-element.html#attr-iframe-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 overview=The HTML5 | |Feature users and use cases=Users are web developers looking for a way to isolate content on their site and prevent it from having its default same origin privileges, ability to execute scripts and other normally granted abilities. The HTML5 spec specifies some modifying attributes that can grant permissions such as same origin , executing scripts, navigating the top window and submitting forms, etc. There are other abilities which are always removed in a sandboxed document that cannot be granted. | ||
|Feature users and use cases=Users are web developers looking for a way to isolate content on their site and | |||
|Feature requirements=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 requirements=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. | ||
| Line 27: | Line 26: | ||
* 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 <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 | * 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 | |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 only needs 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 | |Feature implementation plan=* The general approach for removing same-origin privileges 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. In some case, there are additional checks that need to be added to the code to see if a document is sandboxed in a way that would prevent an operation from occurring. | ||
* 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::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 use nsDocShell::SetAllowPlugins(false) to prevent plugins being loaded by a sandboxed IFRAME | ||
| Line 74: | Line 73: | ||
+ const unsigned long SANDBOXED_SCRIPTS = 0x20; | + const unsigned long SANDBOXED_SCRIPTS = 0x20; | ||
</pre> | </pre> | ||
** when the sandbox attribute on an IFRAME element is modified, we will change the flags on the docshell but not the document | ** when the sandbox attribute on an IFRAME element is modified, we will change the flags on the docshell but not the document - the document must be reloaded for the changed flags on the docshell to take effect | ||
*** we will implement this using | *** we will implement this using nsHTMLIFrameElement::AfterSetAttr, | ||
** 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) | ** 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) | ** 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) | ||
| Line 83: | Line 82: | ||
* nsFrameLoader will be modified to assign the null principal to a sandboxed IFRAME (if allow-same-origin is not 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. | ** this also requires modifying surrounding code to be able to force an owner to be set on the loading channel. | ||
** we may be able to implement both cases in one place if we do the null principal assignment at a low enough level in the docshell loading code | ** we may be able to implement both cases in one place if we do the null principal assignment at a low enough level in the docshell loading code | ||
** 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) | ** 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) | ||
| Line 89: | Line 87: | ||
* 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) | * 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 | * 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 | |Feature security review=This feature will definitely need a full security review from the Security Assurance team. I've posted this feature page on dev.security and updated the bug with decisions and implementation plans as implementation has proceeded. Before the security review I will post again to dev.security and encourage review of this feature page and the HTML5 iframe sandbox spec. | ||
|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. | |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. | 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 | |Feature implementation notes=See https://bugzilla.mozilla.org/show_bug.cgi?id=341604 for a patch that attempts to implement HTML5 iframe sandbox. | ||
There's an initial set of tests in that bug as well. | |||
Please see the bug for updates to current status and remaining implementation issues/tasks. | |||
|Feature landing criteria=* Needs a test suite | |Feature landing criteria=* Needs a test suite | ||
* Needs to be compared against other implementations and public test suites for consistency | * Needs to be compared against other implementations and public test suites for consistency | ||
| Line 107: | Line 112: | ||
{{FeatureTeamStatus | {{FeatureTeamStatus | ||
|Feature engineering status=In Progress | |Feature engineering status=In Progress | ||
|Feature engineering notes=Initial implementation done, has received feedback from 3 people. Experimental prototype was rewritten after initial feedback. Test suite | |Feature engineering notes=Initial implementation done, has received feedback from 3 people. Experimental prototype was rewritten after initial feedback. Test suite has been written. Working through remaining implementation issues, then will seek out another round of feedback on the tests and the implementation itself. | ||
}} | }} | ||