Origin set to null when redirected on fetched resource
Reported by
mikkocar...@gmail.com,
Apr 17 2017
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Steps to reproduce the problem: I've set up a working POC at http://rootme.in/fetch, please follow along; 1. Open a your browser's Developer Tools and switch to Network tab 2. Copy & paste the following URL into the address bar http://rootme.in/fetch?url=http://request.rootme.in/redirect%3furl=http://rootme.in (request.rootme.in is an alias of rootme.in) Or you can simply send fetch request to above URL from your browser's console while in rootme.in. You'll see an error message in console saying "Origin 'null' is not allowed to access the requested resource". If you noticed, it's the same domain that we got redirected to i.e. rootme.in. Technically, it's communicating same domain so it should be able to read received response anyway. Again, to verify the issue- please copy & paste the following URL; http://rootme.in/fetch?url=http://request.rootme.in/redirect%3furl=http://httpbin.org You, now, should be able to read received response. However, if you inspect, you'll see the sent origin is 'null' again. What is the expected behavior? The expected behavior is to retain "Origin" along the way. The fetch spec says; > The `Origin` header is a version of the `Referer` header that does not reveal a path. The referrer, however, is retained across all requests. What went wrong? - Origin header wrongly interpreted as being 'null'. - Same-origin communication prevented due to intermediate cross-domain redirect To clarify my second point, you can change above URL to; http://rootme.in/fetch?url=http://rootme.in/redirect%3furl=http://rootme.in/ The redirector domain above has been changed to rootme.in which is originating domain itself. So, now we'll be able to read response as with same-domain communication. Changing final destination to httpbin.org; http://rootme.in/fetch?url=http://rootme.in/redirect%3furl=http://httpbin.org Now, if you inspect, it retains Origin header. Did this work before? N/A Chrome version: 57.0.2987.133 Channel: stable OS Version: Flash Version: The redirector script must be served with 'Access-Control-Allow-Origin: *' or with specified domain. Otherwise, redirection fails.
,
Apr 18 2017
,
Apr 19 2017
tyoshino@: Can you triage this, please?
,
May 12 2017
rootme.in and request.rootme.in are not same origin. See https://html.spec.whatwg.org/multipage/browsers.html#same-origin for the definition of same origin-ness. Since the origin of the page "http://rootme.in/fetch?url=http://request.rootme.in/redirect%3furl=http://rootme.in" is "http://rootme.in", the request by fetch() call to "http://request.rootme.in/redirect?url=http://rootme.in" is cross-origin. See the step 10 of HTTP-redirect fetch algorithm at https://fetch.spec.whatwg.org/#http-redirect-fetch. Here: - CORS flag is set since current url's origin ("http://request.rootme.in/") and request's origin ("http://rootme.in/") are not same origin and therefore HTTP fetch was performed with CORS flag set. See the step 12 of the Main fetch algorithm at https://fetch.spec.whatwg.org/#main-fetch. - location URL is "http://rootme.in/" as the Location header in the response for "http://request.rootme.in/redirect?url=http://rootme.in" is "http://rootme.in". This is not same origin with request's current url's origin which is http://request.rootme.in. So, as specified, request's origin is set to unique opaque origin before following the redirect. This gets serialized into "null".
,
May 13 2017
Yeah, it appeared to be following what fetch spec says. Apologies for confusion.
,
May 22 2017
Thank you for confirming. Closing. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by nparker@chromium.org
, Apr 18 2017Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Type-Bug