![]() ![]() + * navigation of a nested browsing context, unless those plugins can be + * embed element, the object element, the applet element, or through + * This flag prevents content from instantiating plugins, whether using the + const unsigned long SANDBOXED_TOPLEVEL_NAVIGATION = 0x2 + * This flag prevents content from navigating their top-level browsing + const unsigned long SANDBOXED_NAVIGATION = 0x1 + * nested inside it), and the top-level browsing context. + * the sandboxed browsing context itself (or browsing contexts further + * This flag prevents content from navigating browsing contexts other than 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Ĭontent/base/src/nsSandboxFlags.h contains :.We will use nsDocShell::SetAllowPlugins(false) to prevent plugins being loaded by a sandboxed IFRAME.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. This removes its same origin privileges unless allow-same-origin is specified as part of the sandbox attribute. The general approach for removing same-origin privileges is to give a sandboxed IFRAME a null principal to remove its normal domain/principal.This feature attempts to be compatible with the CSP sandbox directive (see ) by establishing infrastructure where CSP only needs to set the sandbox flags on content documents to have them sandboxed as intended. See W3C Working Draft at and W3C Editor's Draft at. Functional specificationĪn IFRAME with the sandbox attribute (and its various modifying attributes) should behave as outlined in the HTML5 spec. implementing on - the current implementation shouldn't prevent this enhancement from being implemented but there are no plans to implement this at the current time.implementing on - this was discussed on the whatwg list and for will not be implemented at the current time (this matches at least one other implementation).implementing on - this was discussed on the whatwg list, currently we don't want to do this, since the meaning of sandbox on is confusing - it would apply in some contexts and not others.implementing the IFRAME seamless attribute and interactions between it the sandbox attribute.Providing sandboxing above and beyond what's described in the HTML5 spec.This feature requires a comprehensive test suite, as automated as possible for inclusion in the Firefox unit tests - Boris Zbarsky has suggested we also submit this test suite to the W3C for inclusion in their HTML5 test suite. 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. There are other abilities which are always removed in a sandboxed document that cannot be granted. 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. 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. See also bug 341604 "Implement HTML5 sandbox attribute for IFRAMEs" and bug 671389 "Implement CSP sandbox directive" The HTML5 spec specifies a new attribute for the IFRAME element, "sandbox", see. ![]() Landed in FF17 - some followup work remains Please use "Edit with form" above to edit this page. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |