Re: CSP not being applied to <applet> tag

> Uuuuggggghhhhh...... so it falls to the plugin itself to enforce the policy.
> But of course, the ones that don't are the ones you really want to stop the
> most.

Exactly. The broader problem is what to do about loads directly by the
plugin. As bz noted, the applet tag does not involve any gecko code.
The Chrome implementation also seems to have a similar problem with
the object tag http://crbug.com/320796 (I could be wrong though, I
don't know much about the Chrome plugin api)

Maybe, CSP should consider a iframe sandbox like design, which calls
plugins "secure" if they support sandbox. Similarly, CSP could by
default  block all plugins unless they explicitly support CSP. If you
want plugins that don't support CSP to work, you have to say something
like 'allow-unsafe-plugins' as a directive for object-src. After all,
if the plugin handles the load there is no guarantees that the browser
can provide (Additional code in the browser can take care of the
initial load but what about redirects or secondary loads by the
plugin?).

See http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#concept-plugin-secure

--dev


> Maybe we should at least special case a calculated policy of object-src
> 'none' to just block any plugin instantiation? Or is support for media-types
> in 1.1 close enough down the road?
>
>
> On Wed, Nov 13, 2013 at 6:07 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>>
>> On 11/13/13 5:10 PM, Erik Larsson wrote:
>>>
>>> The CSP specification (http://www.w3.org/TR/CSP/#object-src) seems to
>>> explicitly state that loading Java Applets should be configurable using
>>> default-src.
>>
>>
>> As far as I know, browsers don't do any loading of stuff for <applet>.
>> They just instantiate the Java plug-in, and it does the network access
>> itself.
>>
>> Certainly the code that handled <object data> and <embed src> in Gecko
>> does no URI loading in the Java applet case.
>>
>> -Boris
>>
>

Received on Tuesday, 19 November 2013 19:17:08 UTC