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

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