W3C home > Mailing lists > Public > public-webappsec@w3.org > April 2015

Re: HTML Imports and CSP

From: Nathan Sobo <nathan@github.com>
Date: Tue, 7 Apr 2015 11:21:59 -0600
Message-ID: <CAPEVo5J2sjQHDeB7jDm2JgG7Fd==GL350kzRU4QdUU7MVv36NQ@mail.gmail.com>
To: Jeffrey Yasskin <jyasskin@google.com>
Cc: Mike West <mkwst@google.com>, Dimitri Glazkov <dglazkov@google.com>, Devdatta Akhawe <dev.akhawe@gmail.com>, Brad Hill <hillbrad@gmail.com>, Joel Weinberger <jww@google.com>, Justin Schuh <jschuh@google.com>, Justin Fagnani <justinfagnani@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
> 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.

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
>
Received on Tuesday, 7 April 2015 17:22:27 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:12 UTC