- From: Brad Hill <hillbrad@gmail.com>
- Date: Tue, 2 Sep 2014 08:38:53 -0700
- 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