Re: Content Security Policy and iframe@sandbox

Oh, sorry I clicked send before time.. I need to install that "Undo" lab
again ;)

Anyway, regarding the plugins. As said before.. I still see
iframe@sandboxas useful.. and plugin loading seems to be another use
case of it.. Which I
missed, but the point is still valid.

Plugins would (still) be disabled in sandboxed iframes of course. I hope
that clarifies things.
Greetz!!

-- Eduardo



On Sat, Feb 12, 2011 at 7:41 PM, 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
>> >>
>> >
>> >
>>
>
>