Re: HTML Imports and CSP

On Tue, Apr 7, 2015 at 12:08 PM Brad Hill <hillbrad@gmail.com> wrote:

> <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)
>
Yes, I think you're correct, but I think we're suggesting that this has to
change. For better or for worse, CSP has assumed that "you" (the developer)
have control of pretty much all of the document of your page, with the
exception of scripts you import dynamically changing things.

HTML Imports fundamentally change this because the entire premise is that
document structure is brought in wholesale and hidden from the importing
document. Requiring that developers understand that structure (a) violates
the encapsulation that HTML imports are trying to provide, and (b) is
probably next to impossible on a practical level.

>
> 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?
>
Yes, this is the hard part, and I'm not sure we resolved it. I suspect
that, inevitably, this has the potential to lead to confusing cases where
an imported document modifies something that's "part of" the
"outer"/"importing" document, and then it will be confusing which CSP
applies. Having dealt with something similar in the case of Chrome
extensions, I suspect the answer is "if you modify the importing document,
the change is subject to the importing document's CSP, so tread carefully."

>
> 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.
>
Yeah, agreed. That's true of scripts, too. Isn't that what "default-src" is
for?

>
> :(
>
> 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.
>
I think that, as a practical matter, we're already seeing that knowledge of
a module's structure isn't a reasonable thing to require or assume. We
escape this with script-src because we say "anything goes once you include
a script," but the earlier parts of this thread were making the case that
we shouldn't do that with HTML imports.

Lots of imports assume policies that importing documents don't assume (e.g.
inline scripts or img sources). Your suggestion either means that for
foobar.com to use some BigCompaniesAwesomeModule that has inline scripts,
they need to either (a) allow inline scripts for foobar.com, or (b)
convince BigCompany to change their module. (b) is unlikely and (a) should
make us sad.

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