W3C home > Mailing lists > Public > public-web-security@w3.org > February 2011

Re: Content Security Policy and iframe@sandbox

From: Adam Barth <w3c@adambarth.com>
Date: Sat, 12 Feb 2011 11:59:06 -0800
Message-ID: <AANLkTikYn-e9D2zDmDzVD45w-sKytXOT54E+51YB0zEr@mail.gmail.com>
To: "sird@rckc.at" <sird@rckc.at>
Cc: public-web-security@w3.org
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
>> >>
>> >
>> >
>
>
Received on Saturday, 12 February 2011 20:00:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 12 February 2011 20:00:11 GMT