Re: Content Security Policy and iframe@sandbox

Humm yes, that sounds better.

FWIW, thinking more about it. this use case doesn't need CSP, it works with
just allow-same-origin and no allow-scripts.

> 1. Parse HTML safely using the browser without JS execution.
>  Any alternative that creates DOM could be dangerous if lives
>   in the same window.

In an unrelated note, it also works on IE with security="restricted".. (so,
chrome+ff4+ie6 provide the tools to do safe and native html parsing).

Greetz!!

-- Eduardo



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

> Presumably form-action would be a better name than form-src.  :)
>
> Adam
>
>
> On Sat, Feb 12, 2011 at 11:41 AM, sird@rckc.at <sird@rckc.at> wrote:
> > 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
> >> >>
> >> >
> >> >
> >
> >
>