- From: Mike West <mkwst@google.com>
- Date: Tue, 31 Mar 2015 11:12:26 +0200
- 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>
- Message-ID: <CAKXHy=fxHsmcmu9sRfsTtPTyqNJcuN0P2M189MNvMV7Ebzh_JQ@mail.gmail.com>
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