Issue metadata
Sign in to add a comment
|
Response.redirected and a new security restriction |
||||||||||||||||||||||||||||||||||||||||||||
Issue descriptionChange description: - Add .redirected attribute to Response class of Fetch API. Web developers can check it to avoid untrustworthy responses. - To avoid the risk of open redirectors (https://cwe.mitre.org/data/definitions/601.html) introduce a new security restriction which disallows service workers from responding with a redirected response to requests with a redirect mode different from "follow". This restriction also disallows to respond to navigation requests with redirected responses, because the redirect mode of navigation request is “manual”. Changes to API surface: interface Response { ... readonly attribute boolean redirected; ... }; Links: Public standards discussion: https://github.com/whatwg/fetch/issues/79 Spec of Response.redirected: https://fetch.spec.whatwg.org/#dom-response-redirected Spec change: https://github.com/whatwg/fetch/commit/e54f6bd1e75f46cd4b8202f5ee3bfa68e9ded906 MDN: https://developer.mozilla.org/en-US/docs/Web/API/Response/redirected Support in other browsers: Edge: Edge has implemented Fetch API, but has not implemented Response.redirected attribute. Edge has not implemented Service Worker. (Checked with Edge 38.14393.0.0) Firefox: Firefox has already implemented Response.redirected and the new security restriction in Firefox 49 (Release channel since September 20, 2016) which means that the impacted websites are already broken in Firefox. (https://www.fxsitecompat.com/en-CA/docs/2016/fetch-and-request-now-throws-if-redirect-is-detected-when-in-non-follow-redirect-mode/). Safari: Safari has implemented Fetch API and Response.redirected attribute (https://trac.webkit.org/changeset/201324). And shipped in Technology Preview. But not implemented Service Worker. Internet Explorer: No support for Fetch API and Service Worker.
,
Nov 29 2016
Intent to Implement and Ship: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ZPaAeG3N0tw Entry on the feature dashboard: https://www.chromestatus.com/feature/6667148676038656
,
Nov 29 2016
,
Nov 29 2016
,
Jan 11 2017
After 57.0.2951.0, Chrome shows the error messages on DevTools. As I announced in blink-dev, I will introduce the restriction in M59. https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ZPaAeG3N0tw
,
Feb 14 2017
,
Mar 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/343f57b30319e935a538ef99853a8eaafe7926e5 commit 343f57b30319e935a538ef99853a8eaafe7926e5 Author: horo <horo@chromium.org> Date: Fri Mar 17 11:24:30 2017 [ServiceWorker] Introduce the new security restriction of redirected response. This CL blocks responding to requests which redirect mode is not 'follow' with redirected responses. BUG= 669363 , 658249 Review-Url: https://codereview.chromium.org/2755643004 Cr-Commit-Position: refs/heads/master@{#457736} [delete] https://crrev.com/532ac1199af575790db7370f5e197909482ffe50/third_party/WebKit/LayoutTests/external/wpt/service-workers/service-worker/fetch-request-redirect.https-expected.txt [modify] https://crrev.com/343f57b30319e935a538ef99853a8eaafe7926e5/third_party/WebKit/LayoutTests/external/wpt/service-workers/service-worker/fetch-request-redirect.https.html [delete] https://crrev.com/532ac1199af575790db7370f5e197909482ffe50/third_party/WebKit/LayoutTests/http/tests/serviceworker/fetch-request-redirect.html [delete] https://crrev.com/532ac1199af575790db7370f5e197909482ffe50/third_party/WebKit/LayoutTests/http/tests/serviceworker/resources/fetch-request-redirect-iframe.html [modify] https://crrev.com/343f57b30319e935a538ef99853a8eaafe7926e5/third_party/WebKit/Source/modules/serviceworkers/FetchRespondWithObserver.cpp
,
Mar 22 2017
,
Mar 30 2017
|
|||||||||||||||||||||||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||||||||||||||||||||||
Comment 1 by horo@chromium.org
, Nov 29 2016This new security restriction impacts existing code. Scenario: Let’s assume that your service worker behaves as follows: 1. the install event handler stores the response of ‘/’ to the CacheStorage and, 2. the fetch event handler responds to the navigation request of ‘/’ with the response in the CacheStorage. self.oninstall = evt => { evt.waitUntil( caches.open('cache_name') .then(cache => { return fetch('/').then(response => cache.put('/', response)); })); }; self.onfetch = evt => { if (new URL(evt.request.url).pathname != '/') return; evt.respondWith(caches.match(evt.request, {cacheName: 'cache_name'})); }; Problem: If the server respond to the request of ‘/’ with a redirect response to ‘/index.html’, the response in the install event handler is, in effect, a redirected response. So with the new security restriction, respondWith() in the fetch event handler will fail. Solution: To avoid this failure, you have 2 options. 1. You can either change the install event handler to store the response generated from res.body: self.oninstall = evt => { evt.waitUntil( caches.open('cache_name') .then(cache => { return fetch('/') .then(response => cache.put('/', new Response(response.body)); })); }; 2. Or change both handlers to store the non-redirected response by setting redirect mode to ‘manual’: self.oninstall = evt => { evt.waitUntil( caches.open('cache_name') .then(cache => Promise.all(['/', '/index.html'] .map(url => fetch(new Request(url, {redirect: 'manual'})) .then(res => cache.put(url, res)))))); }; self.onfetch = evt => { var url = new URL(evt.request.url); if (url.pathname != '/' && url.pathname != '/index.html') return; evt.respondWith(caches.match(evt.request, {cacheName: 'cache_name'})); };