- From: Mike West <mkwst@google.com>
- Date: Mon, 30 Mar 2015 10:01:31 +0200
- To: Devdatta Akhawe <dev.akhawe@gmail.com>
- Cc: Justin Fagnani <justinfagnani@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAKXHy=cvhAMYUwgGCoqM-WB0R6_+5N_CA-nLrQtOK+DmYfU_sA@mail.gmail.com>
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