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

Re: HTML Imports and CSP

From: Mike West <mkwst@google.com>
Date: Tue, 31 Mar 2015 11:12:26 +0200
Message-ID: <CAKXHy=fxHsmcmu9sRfsTtPTyqNJcuN0P2M189MNvMV7Ebzh_JQ@mail.gmail.com>
To: Joel Weinberger <jww@chromium.org>
Cc: Devdatta Akhawe <dev.akhawe@gmail.com>, Justin Fagnani <justinfagnani@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Mon, Mar 30, 2015 at 11:04 PM, Joel Weinberger <jww@chromium.org> wrote:

> All of this is well-and-good for the "static inline" case, as described in
> Adam's original proposal. That is, I certainly agree that nonce/hash + an
> src directive (I have a preference for a new directive, as Dev mentioned,
> but script-src would work as well) would be "good enough" here. But what do
> we then about non-static import case?
>

Glad we agree about the static case!


> That is, as Alex Russell has suggested, we should assume that developers
> will start dynamically generating modules based on untrusted input, and the
> approaches we're discussing would force developers to blindly whitelist
> their contents. Shouldn't we have a way for a module developer who wants to
> specify a policy for their content to do so? Or are all of you arguing that
> we shouldn't expect this issue/we should cross that bridge when we come to
> it?
>

It's not clear to me that we're able to meaningfully deal with dynamic
script in general, and it's already the case that folks have been
dynamically assembling script for years and years. I'm thinking
specifically of the YUI loader which (used to?) allow developers to pick
and choose modules in a single request via GET parameters. I think this is
reasonably common (see Google Fonts, every ad network call ever, JSONP,
etc).

The risk that an HTML import will be dynamically generated doesn't seem to
be different in kind from the risk that a script file will be dynamically
generated, and neither seems unlikely. If we accept the risk for raw
script, it's not clear to me why we wouldn't accept the risk for imports.


> It seems to me that importable documents should be able to specify a
> unique policy for their import (in addition to having the outer page
> specify a policy about what can be imported).
>

I'm fine with that solution as well, though I think there's a lot of
complexity to the implementation (which document is responsible for which
resource request) that will be tough to get right. But in theory, this
seems totally reasonable.

--
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 Tuesday, 31 March 2015 09:13:14 UTC

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