W3C home > Mailing lists > Public > public-webappsec@w3.org > May 2012

Re: Multiple Content-Security-Policy headers

From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 8 May 2012 13:35:43 -0700
Message-ID: <CABcZeBPnfPkyA5x658ZViLoSk+zYwMA66RZ8cbseM0Gf9dayfQ@mail.gmail.com>
To: Tanvi Vyas <tanvi@mozilla.com>
Cc: Adam Barth <w3c@adambarth.com>, Daniel Veditz <dveditz@mozilla.com>, public-webappsec@w3.org
We have time scheduled for it.

On Tue, May 8, 2012 at 1:05 PM, Tanvi Vyas <tanvi@mozilla.com> wrote:
> On 5/8/12 12:43 PM, Adam Barth wrote:
>> On Tue, May 8, 2012 at 11:17 AM, Tanvi Vyas<tanvi@mozilla.com>  wrote:
>>> Thinking about this a bit more, I like Adam's proposed method - take each
>>> source through all policies, if a source is forbidden by any one of them,
>>> the source is not allowed.
>>> This method is more future proof and doesn't require the spec to specify
>>> intersections per directive.  Suppose that in the future we have a
>>> directive
>>> "fruit" with 2 possible values - "apples" and "oranges".  Neither
>>> directive
>>> value is safer than the other, but one policy may have the value "apples"
>>> and another may have the value "oranges".  Using this method, "apples"
>>> will
>>> only be allowed if it passes all policies.  (The corresponding
>>> intersection
>>> rule for this directive would then be to only include this directive in
>>> the
>>> combined policy if it exists in all policies with the same value.
>>>  Otherwise, don't include this directive at all.)
>>> As far as implementation, browser vendors could decide (for performance
>>> reasons) to create per directive intersection rules that would yield the
>>> same behavior as this method.
>>> One question - what would happen if the two policies had different
>>> report-uris?  If we follow this heuristic, we wouldn't send any reports,
>>> correct?
>> Given two policies A and B, the current spec will send violations of
>> policy A to any report URIs in policy A and any violations of policy B
>> to report URIs in policy B.  We can loosen this up to make it
>> permissible to send violations to all the report-uris if that's easier
>> for you to implement.
>> Adam
> Let's discuss this on today's call.
> ~Tanvi
>>> On 5/7/12 6:07 PM, Daniel Veditz wrote:
>>>> On 5/7/12 3:36 PM, Adam Barth wrote:
>>>>> On Mon, May 7, 2012 at 3:29 PM, Tanvi Vyas<tanvi@mozilla.com>    wrote:
>>>>>> Instead, what if we set precedence for different types of headers.  If
>>>>>> firefox see's Content-Security-Policy and X-Content-Security-Policy,
>>>>>> it
>>>>>> ignores X-Content-Security-Policy.  If Webkit sees
>>>>>> Content-Security-Policy
>>>>>> and X-WebKit-CSP, it ignores X-WebKit-CSP.  If either browser see's
>>>>>> two
>>>>>> of
>>>>>> the same headers (2 Content-Security-Policy, 2
>>>>>> X-Content-Security-Policy, or
>>>>>> 2 X-Webkit-CSP), set the policy to default-src 'none'.
>>>>> I'd rather not spec what implementations should do with
>>>>> vendor-prefixed headers, if we can avoid it.
>>>>> I guess I was mistaken.  I thought you and dveditz preferred that the
>>>>> user agent combined multiple policies.  If you and Dan would prefer
>>>>> that multiple Content-Security-Policy headers cause the user agent to
>>>>> enforce default-src 'none', I'm happy to update the spec to require
>>>>> that.
>>>> We definitely prefer combined policies; it seems far more useful
>>>> than default-src 'none'. Whether you apply each in series or try to
>>>> intersect them for performance reasons is an implementation detail
>>>> that should lead to the same result. We're fine having it specified
>>>> that clients should behave "as if" they were combined that way.
>>>> Whether the standard header should obsolete any experimental ones or
>>>> combine with it is a separate issue and was the main thrust of
>>>> Tanvi's mail. I've been assuming we'd obsolete the
>>>> experimental/prefixed versions but you're not wrong that it might be
>>>> useful for experimentation with future features. Probably better
>>>> than prefixed directives, anyway.
>>>> -Dan Veditz
Received on Tuesday, 8 May 2012 20:36:47 UTC

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