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

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

From: Kristijan Burnik <burnik@google.com>
Date: Wed, 27 May 2015 16:27:26 +0200
Message-ID: <CANJwyhW+-_7EFrKaS1aoSb-_Cb=-j1yGMkjLzDqAP73xEt_73A@mail.gmail.com>
To: Jochen Eisinger <eisinger@google.com>
Cc: public-webappsec@w3.org
Thanks!

I'm now fairly convinced that should be the case.
Especially since other resources behave as you describe and XHR/Fetch fail
to do so (Chrome 42).

I have updated the test suite to reflect this failure.
https://github.com/kristijanburnik/web-platform-tests/commit/09f74211bb3d880521af9a9283253c9ac129f2d3

Also added Chromium issue:
http://crbug.com/492615




On Wed, May 27, 2015 at 11:45 AM, Jochen Eisinger <eisinger@google.com>
wrote:

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


-- 

*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 14:28:30 UTC

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