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

Re: HTML Imports and CSP

From: Mike West <mkwst@google.com>
Date: Mon, 30 Mar 2015 10:01:31 +0200
Message-ID: <CAKXHy=cvhAMYUwgGCoqM-WB0R6_+5N_CA-nLrQtOK+DmYfU_sA@mail.gmail.com>
To: Devdatta Akhawe <dev.akhawe@gmail.com>
Cc: Justin Fagnani <justinfagnani@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Fri, Mar 27, 2015 at 11:23 PM, Nathan Sobo <nathan@github.com> wrote:

> Nathan Sobo from the Atom core team here.
>
> For us, the most intuitive solution would be to allow a nonce attribute to
> be specified on an import, similar to how a nonce can be applied to an
> inline script. When applied to an import, the nonce would apply
> transitively to all script tags in all imported documents. It would only
> apply for inline scripts present at the time of import. Script tags added
> to imported documents *after* the fact would not have a nonce automatically
> applied.
>

Yes, `script-src` nonces should probably apply to Imports. As-is, I bet
Chrome is currently applying `style-src` nonces to the `<link>` element.
I'll take a look at that.

On Sun, Mar 29, 2015 at 7:23 AM, Devdatta Akhawe <dev.akhawe@gmail.com>
wrote:

> > I don't think this will be quite enough, since dynamically adding
> <link>s to
> > the document to trigger an import is a common pattern for deferred
> loading
> > of components, and for plug-in systems like what Atom.io is looking to
> use
> > imports for.
>
> Interesting. My read was that this would still be allowed by the
> hypothetical unsafe-static-inline element. The link tag creates an
> import, but doesn't have inline script. The actual inline script is in
> the target of the link tag and the parser is created by a network
> fetch, so wouldn't be a script created parser per se.
>

I should have been more clear about the 'unsafe-static-inline' proposal;
Adam's proposal in the thread I linked was a bit broader than I'd like, but
Dev's read on it is accurate.

I believe such a thing makes sense only in an environment where we can
guarantee that the resources being loaded are, indeed, static. Chrome
extensions and Firefox apps, for instance. It could potentially make sense
in the context of SRI as well, as we could ensure that the data being
loaded was, in fact, what we expected it to be.


> That said, I am actually not a fan of the proposal because I don't
> think it gives us security nor does it solve all use cases.
>

For clarity, I think we should simply allow script inlined into an HTML
Import. There doesn't seem to be additional risk above and beyond what the
author has already accepted by whitelisting the Import's URL as part of the
`script-src` directive. I also think that Chrome and Firefox should
experiment with something like 'unsafe-static-inline' in their respective
walled gardens of static content.

-mike

--
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.)
Received on Monday, 30 March 2015 08:02:20 UTC

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