Re: CSP, Fetch, and frame-ancestors

On Wed, Jun 4, 2014 at 2:56 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

>
> > 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`.
>
> That would be the only case where CSP is applied from a response
> that's a redirect.


I'm less concerned about frame-ancestors, and more concerned with
referrers, really: we want CSP to apply to the referrer sent with
navigational redirects in general. Twitter, for instance, uses `http://t.co`
when redirecting to an insecure host in order to ensure that the referrer
header gets sent along with the request. Several other redirection services
do the same.

If they could set a referrer policy via CSP (e.g. `referrer origin`), they
could use HTTPS instead, which would be ever so excellent.

We need to restructure CSP's implementation in Blink to make that possible,
but it's certainly on my radar.


> What would window.location return in that case? I
> guess the same as if it was a network error? I wonder what that is...
>

It would be a network error, right. I think Blink currently implements XFO
and frame-ancestor by navigating to an origin-sandboxed about:blank, though.

-mike