Re: Content Security Policy and iframe@sandbox

@sandbox and CSP are very different.  The primary difference is who
choses the policy.  In the case of @sandbox, the embedder chooses the
policy.  In CSP, the provider of the resource chooses the policy.

Other minor differences:

1) form-src doesn't exist.
2) It's unclear whether CSP actually stops all script execution in a frame.

Point (2) is somewhat subtle.  Consider the case of a targeted
hyperlink with a JavaScript URL:

<a href="javascript:alert('greetz')" target="theBestFrame">Click me!</a>

Which CSP policy controls whether the JavaScript URL executes?  The
policy of the document that contains the hyperlink or the policy of
the document contained in theBestFrame?  Similarly, does CSP prevent a
plugin from causing script to execute in the context of a document
(e.g., via NPN_Evaluate)?

Relatedly, you can't write a CSP policy that blocks all plugins.
Specifically, consider the Gears plugin, which never loads anything
from a URL.  Even if you have object-src none, the Gears plugin will
still run because it doesn't violate the policy.  However, with
@sandbox, the gears plugin will not run.

In summary, @sandbox disable scripts and plugins at a semantic layer,
whereas CSP block various syntactic ways of executing script or
loading plugins.  That's not to say that one is better or worse than
the other.  They're just different because they have different goals.

Adam


On Sat, Feb 12, 2011 at 11:03 AM, Eduardo Vela <sirdarckcat@gmail.com> wrote:
> Or another alternative could be to drop allow-scripts and allow-forms from
> the sandbox attribute, and use exclusively CSP (and allow-same-origin to
> force content to be in a unique origin).
> Greetz
>
> -- Eduardo
>
>
>
> On Sat, Feb 12, 2011 at 6:46 PM, Eduardo Vela <sirdarckcat@gmail.com> wrote:
>>
>> Hi!
>> In the OWASP Summit 2011, there were 3 sessions regarding in some way
>> iframe@sandbox, which where:
>> * HTML 5 Security
>> * Site Security Policies
>> * DOM Sandboxing
>> And one idea came up in one of the panels (with representatives of
>> M$/Mozilla/Chrome) in where at some point it was being proposed to use CSP
>> to complement iframe@sandbox.
>> After thinking more about it.. I reached the conclusion that in most
>> cases, iframe@sandbox flags are a subset of CSP + text/html-sandboxed.
>> So, this is how I see it:
>> 0. no flags = text/html-sandboxed + allow nothing.
>> 1. allow-scripts = script-src *;options inline-script eval-script;
>> 2. allow-forms = forms-src *;
>> 3. allow-same-origin = lack of text/html-sandboxed
>> The only case I can't emulate is allow-top-navigation.. and I assume there
>> may be more cases where CSP doesn't make sense since it depends on the
>> relation between frame and framer so I wont propose replacing
>> iframe@sandbox, since I still think it's useful, but to either:
>> 1. Expand it to include CSP rules
>> 2. Complement it with a new attribute
>> Now, I see several limitations in iframe@sandbox that are not present in
>> CSP, which would also help.. However, I understand that CSP is way to
>> complicated for random web authors to get it correctly, and the simplicity
>> of iframe@sandbox has this as a huge advantage, so I would like to keep it
>> that simple.
>> Said that, I can imagine something like:
>> <iframe sandbox="allow-same-origin use-policy" policy="<CSP here>">
>> in which case allow-same-origin/lack of allow-same-origin would treat the
>> content as if it had text/html-sandboxed or not (which would be a non-op if
>> the CT is text/html-sandboxed).
>> If you ask, how to mix an allow-scripts with use-policy, it's simple.. The
>> second you get use-policy, all other flags (except allow-same-origin and
>> allow-top-navigation) are ignored.
>> I am still not sure about this, so any feedback is welcome, but I think
>> that a unified sandboxing/content policy syntax would be beneficial.
>> Any thoughts?
>> Now, the use cases:
>> 1. Parse HTML safely using the browser without JS execution. Any
>> alternative that creates DOM could be dangerous if lives in the same window.
>> 2. Be more granular in what is and what is not allowed. Such as,
>> disallowing frames, or allowing only some forms, or even allowing some
>> scripts! (for eye candy or etc..).
>> 3. Provide a safe DOM that you can provide to scripts (javascript)
>> executing sandboxed.
>> Greetings!
>> -- Eduardo
>>
>
>

Received on Saturday, 12 February 2011 19:26:51 UTC