Re: HTML Imports and CSP

On Fri, Mar 27, 2015 at 5:01 AM, Joel Weinberger <jww@chromium.org> wrote:

> Hi all. We, on Chrome, have recently started running into HTML Imports vs
> CSP in several contexts, so I thought I'd bring up (again) the issue of how
> CSP should interact with HTML Imports. Now, at least in Chrome, documents
> that are imported are controlled by the policy of the page. This leads to
> problems where, for example, an imported document has an inline script, but
> the page's policy disallows them, and it's preventing real applications
> from using CSP. To complicate things further, we also have very real
> concerns about content injection problems with HTML importable widgets
> themselves.
>
> After several internal discussions, we've come up with a laundry list of
> potential options for imports and CSP. None of these are complete
> solutions on their own, many of them are strawmen/not workable in their
> immediate form, and some are just wishful thinking (such as the
> "strict-by-default" suggestion). I'll mention my personal thoughts below.
>
>    1. Create a new CSP directive for sources that can be imported.
>    2. Allow imports if the document is on the importing page's script-src
>    whitelist.
>    3. Imported documents can provide their own, independent CSP that is
>    applicable within the import only (and *not* transitively into
>    documents *it* imports).
>    4. Have a strict-by-default policy for imported documents that are
>    always enforced (e.g. inline scripts are never allowed in HTML imports
>    ).
>    5. Pass a script nonce to imports and allow them to inline only with
>    that nonce.
>    6. Have a CSP subdirective that controls what imports can do, somewhat
>    like the iframe sandbox directive, such as if inline scripts are allowed.
>    7. Have a CSP directive that specifies what other
>    directive imports should be treated as (e.g. "apply img-src policy to
>    imports").
>    8. Isolate docs so all of this is a non-issue, i.e. execute scripts in
>    imported docs in their own execution context.
>
> Personally, I think a combination of (1 or 2), (3), and (6) would be the
> best solution. I think that gives us:
> (1 or 2): high level control of what can be imported
> (3): Control over the actual contents of the imported document, but in a
> way that only the creator of the document can possibly enumerate
> (6): External control over a few "important" properties that the top-level
> origin may want to enforce.
>
> Also, I think another possibility is using one of these options in the
> short term (e.g. use the outer page's script-src to allow imports), and go
> with other options in the long term.
>
> Thanks for reading this far :-) Looking forward to hearing your thoughts!
> --Joel
>
>
The reports we're seeing (https://crbug.com/393307) basically boil down to
the single complaint that imported documents very often bundle everything
up (script, style, and markup) into a single document. The general advice
to avoid 'unsafe-inline' means that these bundles don't work on pages that
are otherwise Doing The Right Thing(tm). That's unfortunate. I'd like to
find the smallest thing we can reasonably do to resolve that pain point, as
imports certainly don't seem to be going away (even though Mozilla doesn't
like them :( ).

>From my perspective, the threat model of an imported document is very
similar to a script included via `<script src='...'>`: it can execute
script in the context of your page. That was the logic that lead us to put
imports under `script-src`. If that's the risk we're worried about, then I
think we can safely ignore restrictions on inline script for imported
documents. `script-src` says "Hey, page, you can run script from over
there." That's basically what we're doing for script inlined into those
documents. I don't think I'd be sad about allowing inline script and style
in an imported document, given that that import is controlled by
`script-src`.

---

All that said, my impression is that the _main_ pain point is related to
Chrome's extension and apps system, where Polymer and it's associated
Imports are widespread. Given the unique properties of that environment,
the 'unsafe-static-inline' source expression that Adam proposed in
https://code.google.com/p/chromium/issues/detail?id=393307#c7 seems like a
reasonable first step. We could experiment with that for extensions/apps,
and report back to the group with that implementation experience. I'm still
quite skeptical about exposing that to the web, but who knows? It might be
awesome and totally and completely safe!

--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)