Re: HTML Imports and CSP

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


I didn't realize that you were suggesting completely relaxing the importing
document's security policy on the imported document. That would indeed
solve our problems, but is that really feasible considering the lack of
isolation between the import and the importing page? For example, scripts
in the import can easily manipulate content on the importing page, which
seems like a security issue.

For Atom's use case, we'll be inserting and removing imports dynamically
after the main page "loads" because it's possible to enable and disable
extensions at any time. I suppose we could scan the imported package and
add a bunch of scripts to the CSP whitelist, assuming we're allowed to
modify that list, but it just seems easier to pass a known nonce when we
want to load additional imports.

We're mainly trying to prevent package authors from accidentally injecting
scripts from static content, but we want them to be able to *intentionally*
load scripts. It's kind of a tricky balance for us.


On Tue, Apr 7, 2015 at 11:56 AM, Joel Weinberger <jww@chromium.org> wrote:

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