Re: Content Security Policy and iframe@sandbox

Hey!

Maybe it wasn't clear. I mean't to use the same syntax, not that they have
the same purposes.

form-src was proposed as well in the Summit (to protect against formaction
based XSS).

Greetings!
-- Eduardo



On Sat, Feb 12, 2011 at 7:25 PM, Adam Barth <w3c@adambarth.com> wrote:

> @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
> >>
> >
> >
>