W3C home > Mailing lists > Public > public-webappsec@w3.org > May 2015

Re: [REFERRER] 301 Redirections with cross origin and same origin nodes?

From: Jochen Eisinger <eisinger@google.com>
Date: Wed, 27 May 2015 09:45:59 +0000
Message-ID: <CALjhuieH8W2XXk-HUC_1j3UBhJbGNMWJiVtGMJE_B2_tU9M5Mg@mail.gmail.com>
To: Kristijan Burnik <burnik@google.com>, public-webappsec@w3.org
I think the referrer value should always become less and less detailed
during a network request.

>From that point of view, the behavior with fetch, i.e. that the referrer
value goes from origin to full during the redirect, is wrong.

On Tue, May 26, 2015 at 2:10 PM Kristijan Burnik <burnik@google.com> wrote:

> Greetings to all,
>
> Currently there is an open PR updating the referrer policy test suite with
> tests to support asserting 301 redirections :
> https://github.com/w3c/web-platform-tests/pull/1856
>
> However there is an open question:
>
> Should the final destination of a sub-resource get the same referrer as
> the content (img, link, script) and background requests (XHR, Fetch)?
>
> *We have the following scenario:*
>
> Referrer Policy:
> Origin when Cross Origin
>
> Protocol transition:
> http to http
>
> A priori sub-resource URL:
> cross-origin
>
> Final destination of resource:
> same origin as browsing context
>
> Redirection:
> Start with a cross-origin request for a sub resource which redirects back
> to the same origin of the browsing context. I call it a
> "swap-origin-redirect".
>
> --
>
> What is interesting is that Chrome 42 exhibits the following behavior:
>
> *Image:*
> a.com/index.html ==> b.com/img.py?with_redirect -->
> a.com/img.py?final_dest
> final_dest gets the *origin only URL* (http://a.com/)
>
> See the test
> <https://github.com/kristijanburnik/web-platform-tests/blob/9e6d3021dbed5e2ada8d6912c15ec1d5fc42ca73/referrer-policy/origin-when-cross-origin/http-csp/cross-origin/http-http/img-tag/cross-origin.swap-origin-redirect.http.html> for
> img
>
> *Fetch:*
> a.com/index.html ==> b.com/xhr.py?with_redirect -->
> a.com/xhr.py?final_dest
> final_dest gets the *stripped referrer URL* (http://a.com/index.html)
>
> See the test
> <https://github.com/kristijanburnik/web-platform-tests/blob/9e6d3021dbed5e2ada8d6912c15ec1d5fc42ca73/referrer-policy/origin-when-cross-origin/http-csp/cross-origin/http-http/fetch-request/cross-origin.swap-origin-redirect.http.html> for
> fetch
>
> --
>
> This only occurs when *origin-when-cross-origin* referrer policy is
> applied.
>
> My question is:
>
> Should we differentiate between types of resources (content vs bg
> requests) when we have swap-origin redirects which start of as a
> cross-origin sub-resource request?
>
> Wow, such a mouthful... Drawing diagrams helps... :-)
> Also, see the tests linked above.
>
> Please provide some feedback or suggestions.
>
> --
>
> *Kristijan Burnik*
>
> Software Engineering Intern
>
> burnik@google.com
>
> Google Germany GmbH
>
> Dienerstraße 12
>
> 80331 München
>
> Geschäftsführer: Graham Law, Christine Elizabeth Flores
>
> Registergericht und -nummer: Hamburg, HRB 86891
>
> Sitz der Gesellschaft: Hamburg
>
>
>
Received on Wednesday, 27 May 2015 09:46:37 UTC

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