1730636 - Firefox honors a document's upgrade-insecure-request in same-site navigation, including redirects; breaks www.smartbus.org schedules

Status: ASSIGNED

(Web Compatibility :: Site Reports, defect, P3)

Description

[Karl Dubost💡 :karlcow]

1. Go to https://www.smartbus.org/
2. On the top menu bar, select Schedules
3. 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

[Valentin Gosu [:valentin] (he/him)]

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

[Kershaw Chang [:kershaw]]

I think this is a Web Compatibility issue.

Comment 3

[Daniel Veditz [:dveditz]]

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?

Comment 4

[Karl Dubost💡 :karlcow]

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.

1. https://www.smartbus.org/Schedules/Trip-Planner
2. Click on Link to /Schedules/Trip-Planner with Upgrade-Insecure-Requests: 1
3. It requests https://www.smartbus.org/Schedules/Trip-Planner
4. Response is 301 with location: http://www.smartbus.org/Schedules/Trip-Planner and content-security-policy: upgrade-insecure-requests;
5. It requests again https://www.smartbus.org/Schedules/Trip-Planner after rewriting as https
6. on and on after 10 loops.

What is happening in Edge Canary

1. https://www.smartbus.org/Schedules/Trip-Planner
2. Click on Link to /Schedules/Trip-Planner with Upgrade-Insecure-Requests: 1
3. It requests https://www.smartbus.org/Schedules/Trip-Planner
4. Response is 301 with location: http://www.smartbus.org/Schedules/Trip-Planner and content-security-policy: upgrade-insecure-requests;
5. It requests this time http://www.smartbus.org/Schedules/Trip-Planner without upgrading
6. 200 OK on http://www.smartbus.org/Schedules/Trip-Planner

Comment 5

[Karl Dubost💡 :karlcow]

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.

Bug 1387938 Comment #2

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

[Raul Bucata]

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:

1. Reproducible regardless of the status of ETP.
2. Reproducible on the latest build of Firefox Nightly.
3. Works as expected using Chrome.

Comment 7

[Raul Bucata]

Attachment: Screenshot Firefox

Comment 8

[Raul Bucata]

Attachment: Screenshot Chrome

Comment 9

[Oana Arbuzov [:oanaarbuzov]]

This is still an issue.

Tested with:
Browser / Version: Firefox Nightly 103.0a1 (2022-06-20)
Operating System: Windows 10 Pro

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 11

[Raul Bucata]

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:

1. Reproducible regardless of the status of ETP.
2. Reproducible on the latest build of Firefox Nightly and Release.
3. Works as expected using Chrome.