W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2014

Re: Header Policy Vs. Meta tag policy

From: Mike West <mkwst@google.com>
Date: Wed, 11 Jun 2014 09:20:52 +0200
Message-ID: <CAKXHy=eyYrT7a3m9R=dR9Q+NHBU+zNdOqvWC5aPjx6ifFYfTcQ@mail.gmail.com>
To: Daniel Veditz <dveditz@mozilla.com>
Cc: Kevin Hill <khill@microsoft.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Thanks Dan. I agree with your analysis, and I appreciate you withdrawing
your objection.

I've made this change in



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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:39 UTC