Features/Platform/Iframe Sandbox

From MozillaWiki
< Features‎ | Platform
Revision as of 23:24, 3 November 2011 by Imelven (talk | contribs)
Jump to navigation Jump to search
Please use "Edit with form" above to edit this page.

Status

Iframe Sandbox
Stage Draft
Status In progress
Release target `
Health OK
Status note currently fleshing out the implementation planning trying to nail down issues/questions there

{{#set:Feature name=Iframe Sandbox

|Feature stage=Draft |Feature status=In progress |Feature version=` |Feature health=OK |Feature status note=currently fleshing out the implementation planning trying to nail down issues/questions there }}

Team

Product manager Lucas Adamski
Directly Responsible Individual Ian Melven
Lead engineer Ian Melven
Security lead Curtis Koenig
Privacy lead Sid Stamm
Localization lead `
Accessibility lead `
QA lead `
UX lead `
Product marketing lead `
Operations lead `
Additional members Brandon Sterne

{{#set:Feature product manager=Lucas Adamski

|Feature feature manager=Ian Melven |Feature lead engineer=Ian Melven |Feature security lead=Curtis Koenig |Feature privacy lead=Sid Stamm |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=Brandon Sterne }}

Open issues/risks

  • Top level navigation prevention needs to be disabled not just for clicking links, but also for setting window.location or targeted links (target = "top" or target = <some other frame>) - need to determine where to impose these restrictions in the code, sicking suggested checking out nsContentUtils::TriggerLinks
  • 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

Stage 1: Definition

1. Feature overview

The HTML5 standard specifies a new attribute for the IFRAME element, "sandbox". See also bug 341604 "Implement HTML5 sandbox attribute for IFRAMEs" and bug 671389 "Implement CSP sandbox directive"

2. Users & 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.

3. Dependencies

`

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

Non-goals

Providing sandboxing above and beyond what's described in the HTML5 spec, implementing the IFRAME seamless attribute and interactions between it the sandbox attribute.

Stage 2: Design

5. Functional specification

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)

6. User experience design

`

Stage 3: Planning

7. 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)
  • 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)
    • when the sandbox attribute on an IFRAME element is modified, we will change the flags on the docshell but not the document
  • 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

8. Reviews

Security review

This feature will likely need a full security review from the secteam.

Privacy review

`

Localization review

`

Accessibility

`

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

Operations review

`

Stage 4: Development

9. Implementation

`

Stage 5: Release

10. Landing criteria

` {{#set:Feature open issues and risks=* Top level navigation prevention needs to be disabled not just for clicking links, but also for setting window.location or targeted links (target = "top" or target = <some other frame>) - need to determine where to impose these restrictions in the code, sicking suggested checking out nsContentUtils::TriggerLinks

  • 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 bug 341604 "Implement HTML5 sandbox attribute for IFRAMEs" and 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 dependencies=` |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 non-goals=Providing sandboxing above and beyond what's described in the HTML5 spec, implementing the IFRAME seamless attribute and interactions between it the sandbox attribute. |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 ux design=` |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)

  • 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)
    • when the sandbox attribute on an IFRAME element is modified, we will change the flags on the docshell but not the document
  • 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 privacy review=` |Feature localization review=` |Feature accessibility review=` |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. |Feature operations review=` |Feature implementation notes=` |Feature landing criteria=` }}

Feature details

Priority Unprioritized
Rank 999
Theme / Goal Security, Privacy
Roadmap Security
Secondary roadmap `
Feature list `
Project `
Engineering team Security

{{#set:Feature priority=Unprioritized

|Feature rank=999 |Feature theme=Security, Privacy |Feature roadmap=Security |Feature secondary roadmap=` |Feature list=` |Feature project=` |Feature engineering team=Security }}

Team status notes

  status notes
Products ` `
Engineering ` `
Security ` `
Privacy ` `
Localization ` `
Accessibility ` `
Quality assurance ` `
User experience ` `
Product marketing ` `
Operations ` `

{{#set:Feature products status=`

|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=` |Feature security health=` |Feature security notes=` |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}


Retrieved from "https://wiki.mozilla.org/index.php?title=Features/Platform/Iframe_Sandbox&oldid=364519"