Re: HTML Imports and CSP

On Tue, Apr 7, 2015 at 10:22 AM Nathan Sobo <nathan@github.com> wrote:

> > they'll also need to enable those, probably with hashes since
> unsafe-inline enables too much.
>
> (Oops, forgot to reply all.)
>
> I hope you'll also consider a nonce-based solution for imports as it will
> greatly simplify our implementation in Atom.
>
Nathan, can you explain how this solution isn't sufficient for Atom? Is it
that you *want* the outer document to enforce a "minimum CSP" on imports,
and this solution doesn't provide that?

>From a usability perspective, I think this does provide a solution for you
because by default, imports wouldn't have a policy at all, so "anything
goes." I abstractly agree that having a page require a "minimum" CSP for
modules would make sense to some degree, but I think that's a separate
conversation/feature request.

>
> On Tue, Apr 7, 2015 at 11:04 AM, Jeffrey Yasskin <jyasskin@google.com>
> wrote:
>
>> On Tue, Apr 7, 2015 at 9:53 AM, Mike West <mkwst@google.com> wrote:
>> > On Tue, Apr 7, 2015 at 5:43 PM, Dimitri Glazkov <dglazkov@google.com>
>> wrote:
>> >>>
>> >>> On Tue, Apr 7, 2015 at 1:39 PM, Mike West <mkwst@google.com> wrote:
>> >>>>
>> >>>> After thinking about this a bit more over the holidays, I think I'm
>> more
>> >>>> in agreement with you than I thought, Dev. :)
>> >>>>
>> >>>> What do you think about this:
>> >>>>
>> >>>> 1. Move imports to `import-src` (we'll need to measure usage in
>> Chrome,
>> >>>> but assuming this is mostly an extension thing at this point, it
>> should be
>> >>>> doable).
>> >>>>
>> >>>> 2. Give imports their own policy (that is, no longer inherit from the
>> >>>> containing document) like Workers and frames, which would enable
>> them to
>> >>>> either whitelist `unsafe-inline` themselves, or use nonces/hashes
>> whatever.
>> >>
>> >>
>> >> This seems encouraging. What is the bottom line for developers using
>> CSP?
>> >> What is the least that they need to do in order to make HTML Imports
>> usable?
>> >
>> >
>> > The very least? Nothing at all. No CSP, no problem, right?
>> >
>> > The least they should do to maintain the security invariants they had
>> before
>> > is add an `imports-src` directive to their policy that allows Imports
>> from a
>> > set of sources. We'd almost certainly want to change Chrome
>> extension/app's
>> > default CSP to include such a directive.
>> >
>> > Maybe `import-src` would even default to `script-src`, in the same way
>> (the
>> > deprecated) `frame-src` defaults to `child-src` (which defaults to
>> > `default-src`)? We've avoided these chains in the past, but it might
>> make
>> > sense here, as Imports can and do execute script, and the vast majority
>> of
>> > sites wouldn't know that they should think about restricting them.
>>
>> Further, they should put a CSP on the HTML Imports themselves, right?
>> Otherwise the Import can pull scripts from bad places and be XSS'ed
>> itself. If the HTML Import contains inline script blocks, they'll also
>> need to enable those, probably with hashes since unsafe-inline enables
>> too much. Has anyone written a build step for grunt/gulp/etc that
>> generates hashes for a static file? What needs to be done to serve
>> those hashes from most CDNs?
>>
>> Jeffrey
>>
>
>