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

Re: CSP Level 2 last call comment

From: Brad Hill <hillbrad@gmail.com>
Date: Tue, 2 Sep 2014 08:43:29 -0700
Message-ID: <CAEeYn8gQDsZx6728FgFnpYkfpP+GxsdpqiL=8zPO_-7iJ4cMOw@mail.gmail.com>
To: Devdatta Akhawe <dev.akhawe@gmail.com>
Cc: Mike West <mkwst@google.com>, "Hill, Brad" <bhill@paypal.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
One more thing - the threat model here isn't granular below SOP.  The
assumed attacker is an already established foreign document context,
and the execution model for such only has a security granular to the
origin level.  This is unlike loading content into your own execution
context, where you might assume some additional granularity of
permissions at the file-system level of a trusted server before you
create or add to an execution context.

-Brad

On Tue, Sep 2, 2014 at 8:38 AM, Brad Hill <hillbrad@gmail.com> wrote:
> Allowing paths would also allow brute-forcing of information about the
> framing ancestors across origins.  We have to accept at least leaking
> the origin for feature-completeness vis-a-vis X-Frame-Options and
> ALLOW-FROM, but I think allowing paths to be disclosed would lead to
> similar issues as we've faced with paths and redirects.
>
> -Brad
>
> On Mon, Sep 1, 2014 at 2:55 PM, Devdatta Akhawe <dev.akhawe@gmail.com> wrote:
>> I was thinking it could lead to a misunderstanding: e.g., I might
>> specify frame-ancestors https://example.com/trusted
>>
>> but https://example.com/untrusted can just do history.pushState to
>> https://example.com/trusted and then the framing would work.
>>
>> Given the client-side nature of the directive, I think the maximum
>> granularity it should support is origin. Any granularity lower than
>> that is also ok: so https: is fine, only example.com is fine. Path
>> granularity might be too fine-grained.
>>
>> cheers
>> Dev
>>
>> On 1 September 2014 06:51, Mike West <mkwst@google.com> wrote:
>>> What's the rationale for the restriction? I don't see the threat of
>>> increased granularity at first glance.
>>>
>>> Any why not reduced granularity? `frame-ancestors https:` seems like a
>>> reasonable thing for a page to ask for.
>>>
>>> -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 Thu, Aug 28, 2014 at 7:05 AM, Devdatta Akhawe <dev.akhawe@gmail.com>
>>> wrote:
>>>>
>>>> I vote for accepting only a list of host-sources and failing closed if
>>>> a source-list is given. I am worried that silently discarding
>>>> extra path information might give devs a false sense of security.
>>>>
>>>> On 27 August 2014 08:53, Hill, Brad <bhill@paypal.com> wrote:
>>>> > One final last call comment if it’s not too late…
>>>> >
>>>> >
>>>> >
>>>> > The directive-value ABNF for frame-ancestors is just listed as
>>>> > “source-list”.
>>>> >
>>>> >
>>>> >
>>>> > The previous ABNF when it was in the UISecurity spec, and previous
>>>> > X-Frame-Options behavior, should only accept a list of host-sources, or
>>>> > should discard any extra path information and use only the Origin.  This
>>>> > is
>>>> > not reflected in current spec text.
>>>> >
>>>> >
>>>> >
>>>> > -Brad
>>>>
>>>
>>
Received on Tuesday, 2 September 2014 15:43:57 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:06 UTC