Re: HTML Imports and CSP

<hat=individual>

Do I misunderstand the model for HTML imports here?  I thought there was no
new document context created and no security boundary between it and the
importing page.  (which makes me sad, and which I commented on early-on,
but am not aware that the model ever changed)

The idea that an import is not governed by the page into which it is
inlined seems very against the rest of the pattern of CSP.  It makes sense
for e.g. a Worker to come with its own policy, as they may be shared among
several resources, have a limited interface, and must be same origin.

If I <script src=xyz> that content might further try to import other
content, but the CSP for the importing resource must allow it.  (ReCaptcha
is a good example of this pattern.)

But if content that gets inlined directly into the DOM gets to supply its
own policy... well, how do we even distinguish at that point which requests
are coming from it vs. the importing context?  And why isn't that just a
total invalidation of the CSP policy?

As someone who might be applying a policy to try to contain code (no,
random n00b developer, you can't just can't add that .js from jquery's CDN,
and sorry 3rd-party ad, you can't XHR to evil.com) this means I either have
to totally disallow imports, or it's goat-rodeo time.

:(

If an import becomes part of the resource, it should be governed by policy
delivered with that resource.  If that means you have to understand the
dependencies of things you import, (and they have to document and conform
to them!) I'm not sure that is a bad thing, either.

-Brad


On Tue, Apr 7, 2015 at 10: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
>>>
>>
>>