- From: Mike West <mkwst@google.com>
- Date: Wed, 11 Jun 2014 09:20:52 +0200
- To: Daniel Veditz <dveditz@mozilla.com>
- Cc: Kevin Hill <khill@microsoft.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAKXHy=eyYrT7a3m9R=dR9Q+NHBU+zNdOqvWC5aPjx6ifFYfTcQ@mail.gmail.com>
Thanks Dan. I agree with your analysis, and I appreciate you withdrawing your objection. I've made this change in https://github.com/w3c/webappsec/commit/f697c40eea84b6c57480c0e3783993a47ebdc3d5 WDYT? -mike -- Mike West <mkwst@google.com> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 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.) On Wed, Jun 11, 2014 at 7:56 AM, Daniel Veditz <dveditz@mozilla.com> wrote: > On 6/9/2014 9:50 PM, Mike West wrote: > >> I'd prefer to maintain the ability to tighten a page's policy, as I >> think there are totally valid use cases for such a thing, but so far >> I've been the only one in favor of that, and the spec reflects my >> understanding of the group's consensus. >> > > There are definitely good and valid use cases for tightening a site-wide > header policy via <meta> document policy. The concern was whether an > injected <meta> policy can break a site that was otherwise not broken, much > as people were able to use early versions of the XSS filtering in IE to > cause security problems on (a very few) sites that otherwise were not > broken. > > Turning off an entire site's scripts in CSP 1.0 was not likely to do > anything other than break the page, but with CSP 1.1's support of path > whitelisting you could theoretically intersect a header policy of > script-src 'self' with an injected policy that whitelists individual > self-hosted scripts except for the one whose omission will leave some > important checks undone. > > That's the fear--but I guess it all hinges on the fact that the victim > site did have an injection problem. If there's no header CSP the site loses > anyway (why inject <meta> when you can inject <script>?). If there is a > header CSP and we allow <meta> policies there's a slight risk of being able > to open a security hole. It's tempting to just blame the site with the > injection problem, but presumably if they were confident in their > perfection they wouldn't need to be using CSP. > > We could add a 'no-meta' header directive--or more generally a > 'final-policy' that could help protect against the slight risk of header > injection--but I don't realistically expect anyone to use them so I'm not > seriously proposing it. > > I withdraw my objection to combining header and <meta> CSP. > > -Dan Veditz >
Received on Wednesday, 11 June 2014 07:21:45 UTC