Re: why does plugin-types inherit to nested browsing contexts?

hm .. to be honest, the spec still reads like it forces the
plugin-type directive on the iframe resource (HTML page). Is that
intentional or am I bad at reading the spec?

Also, what about <iframe src="data:text/html,<iframe src=...>"> Does
plugin-types inherit to the second iframe inside? What if it was an
object tag?


Separately, I am a bit confused why you are worried about this case.
Why not apply the same logic to images then: See
http://htmlpad.org/csp-img-test/
Developers might think "img-src 'none' made me think I can't show any images"

There is a big difference between iframes and direct plugin includes.
When someone embeds the plugin directly in an iframe, it doesn't get
stuff like 'allowScriptAccess' etc. For me personally, non frame-src
directives applying to iframes makes it very weird and hard to reason
about CSP. It is much easier to reason (for a web app security person
like me) about a mechanism that only applies to the current context
and "frame-src applies to iframes that load in the current context."
If we are (understandably)  worried about being able to iframe non
HTML content, I am all for creating a separate directive for that;
that disallows this sort of navigations to images, plugins, etc in an
iframe. But that should be separate and apply to fonts/images, and so
on, imo.


cheers
Dev

On 26 February 2015 at 02:15, Mike West <mkwst@google.com> wrote:
> That's just poor phrasing on my part. The intent of that section was to
> control the case where a plugin is embedded via an <iframe> element. That
> is, the plugin document is created _directly in_ a _directly nested_
> browsing context.
>
> That is, the intent is to allow authors to say "Please don't allow me to
> directly embed anything other than PDF, please.". The intent is not to reach
> down into embedded documents.
>
> I've attempted to fix the text in
> https://github.com/w3c/webappsec/commit/7a31bfef36eb6b7047e61388bc17379abd2f10c9.
> WDYT?
>
> -mike
>
>
>
> --
> Mike West <mkwst@google.com>, @mikewest
>
> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany,
> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
> Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores
> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
>
> On Thu, Feb 26, 2015 at 1:48 AM, Devdatta Akhawe <dev.akhawe@gmail.com>
> wrote:
>>
>> hmm .. isn't the embedding of a SWF inside an SWF is outside the
>> browser's reasoning / security any how, right? The browsing context
>> hierarchy here is the iframe one, I thought. What the current
>> inheritance rules mean is that my csp policy affects all pages I
>> iframe. That is a bit weird. So, I might disallow flash on my site by
>> setting plugin-types; but I can't iframe youtube now, which seems an
>> unnecessary restriction.
>>
>> cheers
>> Dev
>>
>> On 25 February 2015 at 16:29, Emily Stark <estark@google.com> wrote:
>> > Thanks Brad. I think there may be still some distinction between
>> > object-src
>> > and plugin-types that I'm missing: shouldn't object-src also be
>> > inherited?
>> > If foo.com has a policy of object-src allowed.com 'self', and foo.com
>> > embeds
>> > a SWF from allowed.com which embeds a SWF from disallowed.com, isn't
>> > that
>> > also a trivial bypass?
>> >
>> > On Wed, Feb 25, 2015 at 2:39 PM, Brad Hill <hillbrad@gmail.com> wrote:
>> >>
>> >> I'm going to guess this is due to some peculiarities in how Flash and
>> >> PDF
>> >> allow embedding.  In this situation for CSP the plugin document is
>> >> treated
>> >> like a script.  So e.g. a script can be loaded from "allowed.com" but
>> >> can't
>> >> then inject another script element from "disallowed.com" if that's not
>> >> in
>> >> policy.  Similarly, a SWF from "allowed.com" shouldn't be allowed to
>> >> then
>> >> embed another SWF from "disallowed.com", or this would be a trivial
>> >> bypass.
>> >>
>> >> On Wed Feb 25 2015 at 2:23:17 PM Emily Stark <estark@google.com> wrote:
>> >>>
>> >>> While investigating a few CSP bugs in Chrome, I noticed this text in
>> >>> the
>> >>> CSP 1.1 spec for plugin-types:
>> >>>
>> >>> "Whenever the user agent creates a plugin document in a browsing
>> >>> context
>> >>> nested in the protected resource, if the user agent is enforcing any
>> >>> plugin-typesdirectives for the protected resource, the user agent must
>> >>> enforce those plugin-types directives on the plugin document as well."
>> >>> (http://www.w3.org/TR/2014/WD-CSP11-20140211/#plugin-types)
>> >>>
>> >>> Dev (cc'ed) and I found this behavior a little odd and were wondering
>> >>> why
>> >>> plugin-types is inherited. Is the goal to give a developer a way to
>> >>> say
>> >>> "don't allow Flash to appear anywhere in the content area of my page?"
>> >>> Why
>> >>> is this directive inherited but not any others?
>> >>>
>> >>> Thanks,
>> >>> Emily
>> >
>> >
>>
>

Received on Thursday, 26 February 2015 22:52:01 UTC