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:38:53 -0700
Message-ID: <CAEeYn8i2ee-xncJ-pEndAwTLNQaJEEfHf87Cv2QpzgiaQme3GQ@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>
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:39:21 UTC

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