RE: Understanding the security model for the sandbox directive

Yeah, that sounds about right to me. A couple comments inline below. WRT the usage of tokens other than unique origin:

Sandbox (in CSP and HTML5) is about protecting the site from malicious content--not the user necessarily. 
I see the CSP sandbox directive being used in two ways:

	1. A complement to HTML5 Sandbox to protect against convincing a user to navigate to the content outside of a sandboxed iframe.
	2. A server enforced policy for documents that do not need to have certain capabilities. 

In #1, the use cases for restrictions other than unique origin are less compelling (other than it's nice to not have to think about what flags to provide....just use the same ones you used in your HTML sandbox attribute).

In #2, you're protecting certain documents from being a vector for XSS or a similar attack.  For example, I have a static page with a form on it. The page doesn't require script.  As a security measure to prevent against a rogue script being able to manipulate the form values, steal my CSRF token, open annoying (or possibly phishing) popups, etc., I can send a CSP sandbox directive that turns off scripts and popups. This could be a valid scenario even for a page which is the top document. And yes, if the page is somehow navigated elsewhere then these restrictions no longer apply. But the assumption is (as Brad commented below) that it is the author's responsibility to provide the sandbox attribute/directive to each of the documents that need these restrictions (or hosts a document which needs these restrictions).

It's possible there's a proof that some of the tokens aren't needed (for example, you effectively could replace allow-scripts using script-src). But as you point out, I think there's enough value in having token parity with HTML (essentially syntactic sugar).

-Jacob

> -----Original Message-----
> From: Adam Barth [mailto:w3c@adambarth.com]
> Sent: Friday, November 04, 2011 10:18 AM
> To: Hill, Brad
> Cc: dveditz; public-web-security@w3.org; Jacob Rossi
> Subject: Re: Understanding the security model for the sandbox directive
> 
> Ok.  That's something self-consistent that I can spec.  I'm not sure there are
> actually use cases for all the sandbox tokens in that model, but there are
> definitely use cases for some of them and there's a lot of value in aligning
> the list of tokens with the HTML5 sandbox attribute.
> 
> To summarize:
> 
> 1) The sandbox bits in HTML5 are stored in two places: (a) the sandbox
> attribute itself, and (b) associated with the document.  When a document
> gets created, the bits are copied from (a) to (b) so that they're frozen for the
> lifetime of the document, even if the iframe's attributes change.
Correct, assuming a reload of the same document copies the latest values from (a) to (b) again.

> 2) For CSP, the sandbox directive will cause the bits to be set on (b) only.
> That means the bits will apply to the current document but not to future
> documents that occupy the same frame (top-level or otherwise).
To be clear, it applies to (b) and all of its descendants.  So, just like the attribute, if a document can't execute script then a document it frames also cannot execute script (even if that descendent document were sent with a CSP that allowed it). 

> 4) If both CSP and the sandbox attribute supply a sandbox policies, they'll be
> merged using the algorithm in the HTML5 spec (which is currently used to
> merge sandbox bits for nested iframes).
Agreed, though I think HTML5 could be a little clearer. From my testing, Webkit's implementation seems to match our interpretation as well.  Putting the algorithm another way:

There are three possible sources of sandbox restrictions:  
	1. The sandbox attribute of the frame in which the document is hosted.
	2. The sandbox restrictions being applied to the document's parent.
	3. The CSP header sent for the document. 

For a given document, the presence of a given restriction is determined by performing a logical OR of the values from these 3 possible sources.

In other words, if any one of these three sources says you can't execute script then you can't execute script.  

Might also be worth making a few notes (or examples) that define what "sandbox: allow-scripts; script-scr: 'none';" does. I'd take the safe route and say it can't execute script.

> Does that sound reasonable to everyone?
Yup!

> Adam
> 
> 
> On Fri, Nov 4, 2011 at 10:06 AM, Hill, Brad <bhill@paypal-inc.com> wrote:
> > I would say yes, if a page wants protections from content in an iframe, it
> must to set the policy itself, not expect the server to.
> >
> > Basically, if you think the iframed content is potentially untrustworthy and
> needs a sandbox, why would you trust it to sandbox itself?
> >
> > Brad Hill
> > Sr. MTS, Internet Standards and Governance PayPal Information Risk
> > Management
> > cell: 206.245.7844 / skype: hillbrad
> >
> > On Nov 4, 2011, at 10:00 AM, "Adam Barth" <w3c@adambarth.com>
> wrote:
> >
> >> What about the case when user-contrib.paypal-sandbox.com is loaded in
> >> an iframe?  Should we persist the sandbox bits from CSP across
> >> navigation then, or is it the responsibility of the embedding page to
> >> include the sandbox attribute on the iframe they point at
> >> user-contrib.paypal-sandbox.com?
> >>
> >> Adam
> >>
> >>
> >> On Fri, Nov 4, 2011 at 9:55 AM, Hill, Brad <bhill@paypal-inc.com> wrote:
> >>> I think maintaining the sandbox state across navigation is only important
> in a subframe case because the outer framing content must remain
> protected across these events.
> >>>
> >>> For sandboxing applied by the server, it's the server that needs to apply
> protection uniformly, not the browser.
> >>>
> >>> e.g. if I want to block script execution on user-contrib.paypal-
> sandbox.com to help prevent resources there from scripting each other, it
> doesn't matter if a resource there can navigate to evil.example.com and
> execute script from that origin - I have standard SOP protections in that case.
> >>>
> >>> If it navigates elsewhere on user-contrib.paypal-sandbox.com, my server
> can still force the correct sandbox header on that content.
> >>>
> >>> Am I missing something?
> >>>
> >>> Brad Hill
> >>> Sr. MTS, Internet Standards and Governance PayPal Information Risk
> >>> Management
> >>> cell: 206.245.7844 / skype: hillbrad
> >>>
> >>> On Nov 4, 2011, at 9:39 AM, "Adam Barth" <w3c@adambarth.com>
> wrote:
> >>>
> >>>> On Fri, Nov 4, 2011 at 8:26 AM, dveditz <dveditz@mozilla.com> wrote:
> >>>>> What do you mean by "main frame"? The top document, or the
> >>>>> document in a <frame> element in the top document?
> >>>>
> >>>> The top document.
> >>>>
> >>>>> A sandbox directive should apply to any document no matter where
> >>>>> loaded, and should not pollute the container it is loaded in for
> >>>>> future documents. If we start with those as consistency principles
> what works and what doesn't?
> >>>>
> >>>> The unique origin seems to work, but I'm not sure the other tokens
> >>>> work.  The example I gave previously was script execution.  The
> >>>> attacker cannot execute script in the sandboxed document itself,
> >>>> but he/she can trigger a navigation to another (non-sandboxed)
> >>>> document, which can execute script.
> >>>>
> >>>>> What model does IE 10 follow? What have they learned from their
> >>>>> implementation?
> >>>>
> >>>> I'm hoping jrossi can shed some light on that question.
> >>>>
> >>>> Adam
> >>>>
> >>>
> >

Received on Friday, 4 November 2011 18:07:50 UTC