Firefox honors a document's upgrade-insecure-request in same-site navigation, including redirects; breaks www.smartbus.org schedules
Categories
(Web Compatibility :: Site Reports, defect, P3)
Tracking
(Webcompat Priority:P3, firefox94 affected, firefox98 affected, firefox103 affected, firefox111 affected)
Webcompat Priority | P3 |
People
(Reporter: karlcow, Assigned: ksenia)
References
()
Details
(Keywords: webcompat:needs-diagnosis)
Attachments
(2 files)
- Go to https://www.smartbus.org/
- On the top menu bar, select Schedules
- Choose Trip Planner
Expected:
Being redirected to http://www.smartbus.org/Schedules/Trip-Planner
Actual:
Infinite redirection from https to http
with this type of HTTP responses:
HTTP/2 301 Moved Permanently
server: nginx
date: Tue, 14 Sep 2021 04:32:10 GMT
content-type: text/html; charset=UTF-8
content-length: 169
location: http://www.smartbus.org/Schedules/Trip-Planner
x-sucuri-id: 16012
x-xss-protection: 1; mode=block
x-frame-options: SAMEORIGIN
x-content-type-options: nosniff
content-security-policy: upgrade-insecure-requests;
x-sucuri-cache: BYPASS
X-Firefox-Spdy: h2
Somehow in the devtools, Firefox seem to request only https://www.smartbus.org/Schedules/Trip-Planner instead of http://www.smartbus.org/Schedules/Trip-Planner
Safari redirects without issue.
Comment 1•3 years ago
|
||
I think this is happening because the response has:
content-security-policy: upgrade-insecure-requests;
We pass the upgrade flag through loadinfo making subsequent redirects be upgraded, which leads to a redirect-loop.
Comment 2•3 years ago
|
||
I think this is a Web Compatibility issue.
Comment 3•2 years ago
|
||
Chrome and Safari both support upgrade-insecure-requests
but don't have this problem.
If you open a new window and attempt to load https://www.smartbus.org/Schedules/Trip-Planner (note: secure) you get the same redirect as in comment 0 but we do follow the redirect in that case. We appear to be ignoring the upgrade-insecure-request
in the redirect itself.
In the steps given in comment 0, however, the main smartbus page does have content-security-policy: upgrade-insecure-requests;
-- Firefox is applying it to navigations and Chrome+Safari are not. Or rather, Firefox is applying it deeply to navigations, and maybe Chrome+Safari are only rewriting the original URL. According to the spec, same-site navigation links should get upgraded, but it's not clear about after that. A lot of the spec is written in terms of "rewriting links" which would seem to skip redirects. But other parts of CSP are pretty clear about redirects being included, and §4.1 includes the note
Note: Due to [FETCH]'s recursive nature, this algorithm will upgrade insecurely-redirected requests as well as insecure initial requests.
This is curious.
Karl: Firefox appears to be following the spec here. Although we're in the minority and it results in this site being broken, this is a true webcompat problem that needs to be resolved before just accepting it as a Firefox bug. We can try to guess what Chrome and Safari are doing, but then we could end up broken differently elsewhere if we guess wrong. Although the site is broken, we have broken it in the secure direction. If we try to match Chrome and don't get it right we could end up broken in the insecure direction on some other site. Should https://webcompat.com/issues/81130 be re-opened?
Updated•2 years ago
|
Reporter | ||
Comment 4•2 years ago
|
||
The spec issues are hold.
https://github.com/w3c/webappsec-upgrade-insecure-requests/issues
Let's check if there's something on bug trackers of Chromium and WebKit.
So yes we could try to convince the Website to change but we would also need for WebKit and Chromium to change their implementation.
I wonder if Mike West has an opinion or knows about a specific bug on https://bugs.chromium.org/p/chromium/issues
I'm trying to find a bug on WebKit and Chromium if after two requests it abandons the idea of upgrading the request for the sake of fixing the user experience.
What is happening in Firefox.
- https://www.smartbus.org/Schedules/Trip-Planner
- Click on Link to
/Schedules/Trip-Planner
withUpgrade-Insecure-Requests: 1
- It requests https://www.smartbus.org/Schedules/Trip-Planner
- Response is 301 with
location: http://www.smartbus.org/Schedules/Trip-Planner
andcontent-security-policy: upgrade-insecure-requests;
- It requests again
https://www.smartbus.org/Schedules/Trip-Planner
after rewriting as https - on and on after 10 loops.
What is happening in Edge Canary
- https://www.smartbus.org/Schedules/Trip-Planner
- Click on Link to
/Schedules/Trip-Planner
withUpgrade-Insecure-Requests: 1
- It requests https://www.smartbus.org/Schedules/Trip-Planner
- Response is 301 with
location: http://www.smartbus.org/Schedules/Trip-Planner
andcontent-security-policy: upgrade-insecure-requests;
- It requests this time
http://www.smartbus.org/Schedules/Trip-Planner
without upgrading - 200 OK on http://www.smartbus.org/Schedules/Trip-Planner
Reporter | ||
Comment 5•2 years ago
|
||
I wonder in fact if Chrome and WebKit have heuristics to deal with a repeated redirect to the same URI outside of any upgrade-insecure-requests logic. We had something a bit similar on a previous bug.
I probably need to create a test case.
In WebKit the maximum redirection count is 20. There must be something before which is catching it.
https://github.com/WebKit/WebKit/blob/2d5e3f3c862106f80c260e97d7fec83940e20c17/Source/WebKit/NetworkProcess/NetworkLoadChecker.cpp#L138-L140
if (++m_redirectCount > 20) {
handler(redirectionError(redirectResponse, "Load cannot follow more than 20 redirections"_s));
return;
Comment 6•2 years ago
|
||
I was able to reproduce the issue. Following the steps to reproduce, the page returns an "The page isn’t redirecting properly" error message.
Tested with:
Browser / Version: Firefox Nightly 98.0a1 (2022-01-10) (64-bit)
Operating System: Windows 10 PRO x64
Notes:
- Reproducible regardless of the status of ETP.
- Reproducible on the latest build of Firefox Nightly.
- Works as expected using Chrome.
Comment 7•2 years ago
|
||
Comment 8•2 years ago
|
||
Updated•2 years ago
|
Comment 9•2 years ago
|
||
This is still an issue.
Tested with:
Browser / Version: Firefox Nightly 103.0a1 (2022-06-20)
Operating System: Windows 10 Pro
Updated•2 years ago
|
Comment 10•2 years ago
|
||
Redirect a needinfo that is pending on an inactive user to the triage owner.
:denschub, since the bug has recent activity, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•2 years ago
|
Comment 11•1 year ago
|
||
The issue is still reproducible
Tested with:
Browser / Version: Firefox Release 109.0 (64-bit)/ Firefox Nightly 111.0a1 (2023-01-18) (64-bit) /Chrome Version 109.0.5414.75 (Official Build) (64-bit)
Operating System: Windows 10 PRO x64
Notes:
- Reproducible regardless of the status of ETP.
- Reproducible on the latest build of Firefox Nightly and Release.
- Works as expected using Chrome.
Updated•1 year ago
|
Description
•