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

Re: Header Policy Vs. Meta tag policy

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Wed, 11 Jun 2014 11:55:39 -0700
Message-ID: <CAPfop_1_kq34G19HgsUiuGc5fMubRuvdXoy9uotw1fBEWXb3-A@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Daniel Veditz <dveditz@mozilla.com>, Kevin Hill <khill@microsoft.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
I agree with you. I think we should definitely encourage the ability to
lock down further via multiple policies.

I glanced over the directive list and I wonder if whitelisting does
suffice: how about we only allow all *-src and form-action in the meta
element? It does seem conceptually clearer than the blacklisting approach,
where we have to think about threats every time a new directive is added.


On 11 June 2014 10:54, Mike West <mkwst@google.com> wrote:

> We already limit what <meta> can deliver; we should restrict it further,
> however. Currently we block 'report-uri' and 'sandbox'. We should also
> block 'x-xss-protection'. Referrer I'm less concerned about (and we allow
> it to be injected via <meta referrer> today), but it's worth discussing. Do
> note that conflicting rules for both those directives fail in a draconian
> way (block and none, respectively); if the existing policy defines one or
> the other, an injection wouldn't have much impact.
> Regarding Joel's philosophy, I agree in general that blacklisting is the
> wrong approach. CSP is tightly enough defined that I'm less concerned than
> I would be in the general case.
> Regarding Joel's specific questions of hashes and nonces; those do indeed
> add functionality, but only if `script-src` or `style-src` (or
> `default-src`) isn't defined in an existing policy. If those aren't
> defined, then inline script and style are _already_ whitelisted. If they
> are defined, then the injection will fail since it doesn't match _all_
> enforced policies. I don't think there's risk of injection from those items
> in particular.
> -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:32 PM, Devdatta Akhawe <dev.akhawe@gmail.com>
> wrote:
>> I am not sure if a meta tag policy only constrains further. Joel started
>> a related thread a while back [1], and I had mentioned a couple of examples
>> where (it seemed to me) that an injected policy could add behavior instead
>> of just constraining further [2]. Joel also mentioned that he was
>> philosophically opposed to making CSP be "only allows you to constrain
>> further"[3].
>> To mitigate this concern, should we try to limit what meta tag policies
>> can do? For example, do we want to allow an injected policy to add a new
>> report-uri to attacker.com/logger?
>> Regards
>> Dev
>> [1]
>> http://lists.w3.org/Archives/Public/public-webappsec/2014Mar/0001.html
>> [2]
>> http://lists.w3.org/Archives/Public/public-webappsec/2014Mar/0008.html
>> [3]
>> http://lists.w3.org/Archives/Public/public-webappsec/2014Mar/0020.html
>> On 11 June 2014 09:00, Daniel Veditz <dveditz@mozilla.com> wrote:
>>> On 6/11/2014 12:20 AM, Mike West wrote:
>>>> 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/f697c40eea84b6c57480c0e3783993
>>>> a47ebdc3d5
>>>> WDYT?
>>> To be clear, your change does two things and we were mainly talking
>>> about the first:
>>>  * allows use of both HTTP and <meta> CSP
>>>  * allows use of multiple <meta> CSP
>>> The arguments against (and in favor of) multiple <meta> CSP are pretty
>>> much the same as the arguments for and against allowing a combination of
>>> header and <meta> policies. "It's useful, and why not since it can only
>>> tighten policies" vs. "Injection bug in site might be used to circumvent a
>>> feature whose main purpose assumes you need protection from injection
>>> bugs". I'm not objecting to the change, just announcing my intention to sit
>>> in the corner and fret about the possibility.
>>> -Dan Veditz
Received on Wednesday, 11 June 2014 18:56:28 UTC

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