Re: CSP Level 2 last call comment

Ok. That sounds reasonable. I suppose an attacker who had already gotten a
frame onto a page could embed a frame in that frame that could iterate
through possible URLs. Since we already expose origins via
`window.location.ancestorOrigins`, there's no additional risk in the origin
case.

WDYT of
https://github.com/w3c/webappsec/commit/bdc66b7b704a944f4b0a03cfc79fb91c6fa31d65
?

-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 Tue, Sep 2, 2014 at 5:43 PM, Brad Hill <hillbrad@gmail.com> wrote:

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