Open Bug 1730636 Opened 10 months ago Updated 11 days ago

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

Categories

(Web Compatibility :: Desktop, defect, P3)

Firefox 94
Desktop
Windows

Tracking

(Webcompat Priority:P3, firefox94 affected, firefox98 affected, firefox103 affected)

ASSIGNED
Webcompat Priority P3
Tracking Status
firefox94 --- affected
firefox98 --- affected
firefox103 --- affected

People

(Reporter: karlcow, Assigned: ksenia, NeedInfo)

References

()

Details

(Keywords: webcompat:needs-diagnosis)

Attachments

(2 files)

  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.

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.

I think this is a Web Compatibility issue.

Component: Networking: HTTP → Desktop
Product: Core → Web Compatibility

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?

Flags: needinfo?(kdubost)
Summary: Firefox refuses to follow a 301 Permanent redirect from https to http → Firefox honors a document's upgrade-insecure-request in same-site navigation, including redirects; breaks www.smartbus.org schedules

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
Flags: needinfo?(kdubost) → needinfo?(mkwst)

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;

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.
Attached image Screenshot Firefox
Attached image Screenshot Chrome
Assignee: nobody → kdubost
Status: NEW → ASSIGNED
OS: Unspecified → Windows
Priority: -- → P3
Hardware: Unspecified → Desktop

This is still an issue.

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

Assignee: karl+moz → kberezina
You need to log in before you can comment on or make changes to this bug.