W3C home > Mailing lists > Public > public-web-security@w3.org > November 2011

Re: Understanding the security model for the sandbox directive

From: Adam Barth <w3c@adambarth.com>
Date: Fri, 4 Nov 2011 10:18:23 -0700
Message-ID: <CAJE5ia-p6ys3243bd=04QpV1wassXbnchhC60y+iuDnb1bqSCQ@mail.gmail.com>
To: "Hill, Brad" <bhill@paypal-inc.com>
Cc: dveditz <dveditz@mozilla.com>, "public-web-security@w3.org" <public-web-security@w3.org>, "jrossi@microsoft.com" <jrossi@microsoft.com>
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.

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

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

Does that sound reasonable to everyone?

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 17:19:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 4 November 2011 17:19:32 GMT