Re: Header Policy Vs. Meta tag policy

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.

thanks
Dev





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
>>>
>>>
>>
>