Re: Header Policy Vs. Meta tag policy

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