Re: Content Security Policy and iframe@sandbox

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