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

Re: CSP, Fetch, and frame-ancestors

From: Mike West <mkwst@google.com>
Date: Wed, 4 Jun 2014 14:46:01 +0200
Message-ID: <CAKXHy=ewURUvtmVLx0w7N7jmn=udHZEnij=BEMKdFwLUFck8Wg@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Brad Hill <hillbrad@gmail.com>, WebAppSec WG <public-webappsec@w3.org>
On Wed, Jun 4, 2014 at 10:44 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Wed, Jun 4, 2014 at 10:00 AM, Mike West <mkwst@google.com> wrote:
> > On Wed, Jun 4, 2014 at 9:55 AM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
> >> I don't see how it's lower than Fetch by the way. You need to process
> >> all headers before you know if you're going to follow a redirect. So
> >> it seems like you would know this around step 10 of
> >> http://fetch.spec.whatwg.org/#concept-fetch
> >
> > I think it would need to be before step 7 to catch redirects that set
> > frame-ancestors, right?
> How would that work, exactly?
> I guess the other thing here is that this only applies as part of
> navigate actions and those never follow redirects automatically (HTML
> needs to handle them itself for various reasons), so either way I
> think we'd be good.

I'm thinking of a case where a frame loads `http://a.com/`, which redirects
to `http://b.com/`, which redirects to `http://c.com/`. If `b.com` sends
`frame-ancestors 'none'` or `X-Frame-Options: DENY`, I think we shouldn't
follow the redirect to `c.com`.

I doubt that's currently how Blink works, now that I think about it, but
it's probably something we should support.

Received on Wednesday, 4 June 2014 12:46:49 UTC

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