1722044 - Firefox 90 opens urls from third-party apps with Sec-Fetch-Site: cross-site

Status: RESOLVED FIXED

(Core :: DOM: Security, defect, P1)

Description

[Samuel Monsarrat]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:90.0) Gecko/20100101 Firefox/90.0

Steps to reproduce:

• Open a URL from an third-party app when Firefox is the default browser
• Open a url with firefox from the command-line

Actual results:

The initial request is sent with header Sec-Fetch-Site: cross-site

This can cause security minded servers to refuse the request.

Expected results:

The initial request should be with header Sec-Fetch-Site: none (like when the user opens a tab and pastes a URL).

Prior to Firefox 90 the pref "dom.security.secFetch.enabled" was disabled by default. When activated, the initial request stemming from a third-party app was sent with header Sec-Fetch-Site: none

In Firefox 90 not only has dom.security.secFetch.enabled been enabled by default but the behaviour has changed to sending the initial request stemming from a third-party app with header Sec-Fetch-Site: cross-site

The w3c spec on this (https://w3c.github.io/webappsec-fetch-metadata/#sec-priv-considerations) does not explicitly define what should happen for URLs opened via a system API initiated from a third-party app. It does however say that Directly User-Initiated requests should use Sec-Fetch-Site: none.

Regarding URLs coming from an third-party app as cross-site seems incorrect as by definition there was no prior "site", it would seem that Sec-Fetch-Site should be set to "none" as nothing existed prior.

This behaviour change at the same time as dom.security.secFetch.enabled was set to true by default is problematic, why implement a behaviour behind a pref so that it can be tested only to change the behaviour when the pref is enabled by default ?

Firefox 90 is currently the only browser to implement this behaviour, Chromium sets Sec-Fetch-Site: none in the case of URLs opened by third-party apps.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Networking' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Niklas]

Thanks SamueI for the report, I agree that this is a bug and that Sec-Fetch-Site should be set to none here.
I am also seeing that chrome sends Sec-Fetch-User: ?1, which is not as critical as the site value but we could still consider adding that as well.

Just to confirm, Anne what are your thoughts on Sec-Fetch-Site and Sec-Fetch-User here?

Comment 3

[Niklas]

Attachment: Bug 1722044: Consider loads from external applications as user triggered. r=ckerschb,annevk

Comment 4

[Anne (:annevk)]

Chrome's behavior makes sense to me. These are analogous to an address bar navigation.

Comment 5

[Daniel Veditz [:dveditz]]

This is like the arguments over the handling of Same-site cookies on navigation. "Navigation should Just Work!" "No-- the originating site could be malicious and the user didn't intend to open this specific URL". In that case we threw up our hands and implemented both Lax and Strict and let sites figure out which one they wanted to use.

How can we say this is analogous to the user typing an address or clicking a bookmark? In a mobile context, for example, the external app might as well be a separate site in a different tab. There is no meaningful difference between clicking a link in the Element app vs clicking the exact same link from the exact same message viewed through https://chat.mozilla.org, or a Facebook link in the Facebook app vs a Facebook tab.

The goal is to distinguish between "webby" navigations that are controlled by a given (potentially malicious!) website (e.g. links, the window.location setter, form submissions, etc.), and those that are not (e.g. user interaction with a user agent’s address bar, bookmarks, etc).
-- §4.3. Directly User-Initiated Requests

"User Initiated" is probably true often enough that sending Sec-Fetch-User: ?1 makes sense, although we can't ever truly tell with an external app.

This is a case where the spec is not clear enough. We should discuss it with the Web App Sec folks and get the spec clarified, not just blindly copy Chrome which could well be a mistake on their part that they'll change tomorrow.

Samuel: Do you have any concrete cases where "cross-site" is breaking things that "none" fixes? If a site thinks a URL is so dangerous to navigate to that it has blocked normal web navigation, why would they welcome navigations from outside the browser?

Comment 6

[Daniel Veditz [:dveditz]]

I opened https://github.com/w3c/webappsec-fetch-metadata/issues/77

Comment 7

[Sylvain Spinelli]

Samuel: Do you have any concrete cases where "cross-site" is breaking things that "none" fixes?

(Samuel is on vacation)

Yes this change breaks our content editing system (https://scenari.software, an open-source solution mainly used in french countries) where external links from Scenari heavy clients (Xulrunner/Electron apps) are frequently used by our users. SecFetch security can be configured by server, but by default, all the Scenari 5.0 servers currently deployed simply blocks all Sec-Fetch-Site: cross-site requests. It worked perfectly until Firefox 90.

If you decide to maintain this Sec-Fetch-Site: cross-site behaviour, I think we could then allow these requests if Sec-Fetch-Mode:navigate (and add Sec-Fetch-Mode value to Vary response header).

Comment 8

[Samuel Monsarrat]

See Sylvain's comment.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c9fb00a913c9
Consider loads from external applications as user triggered. r=ckerschb,annevk

Comment 10

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/c9fb00a913c9

Comment 11

[Christoph Kerschbaumer [:ckerschb]]

Comment on attachment 9233290 [details]
Bug 1722044: Consider loads from external applications as user triggered. r=ckerschb,annevk

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Sec-Fetch-* Security headers is a new security feature we started to ship in Firefox 90 (see Bug 1695911).
• User impact if declined: Opening links from external apps send the wrong sec-fetch-* security header.
• Fix Landed on Version:
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Not risky, it's only a small tweak which causes web extensions to send a different security header (covered by automated tests).
• String or UUID changes made by this patch: no

Comment 12

[Julien Cristau [:jcristau]]

Comment on attachment 9233290 [details]
Bug 1722044: Consider loads from external applications as user triggered. r=ckerschb,annevk

approved for 91.1esr

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr91/rev/85afb07e80ae

Comment 14

[voltron]

As a sidenote, Firefox Nightly 93.0a1 (2021-08-24) sends "Sec-Fetch-Site": "same-origin" header when using fetch from a WebExtension.

Chrome sends "Sec-Fetch-Site": "none".

Based on comment 2 the initial idea was to make Firefox also set the value to "none" but did something change along the way? The "same-origin" doesn't seem to be a problem at least for some servers though.

Comment 15

[Tom S [:evilpie]]

(In reply to voltron from comment #14)

As a sidenote, Firefox Nightly 93.0a1 (2021-08-24) sends "Sec-Fetch-Site": "same-origin" header when using fetch from a WebExtension.

Chrome sends "Sec-Fetch-Site": "none".

Based on comment 2 the initial idea was to make Firefox also set the value to "none" but did something change along the way? The "same-origin" doesn't seem to be a problem at least for some servers though.

This sounds like bug 1722703, not this one.

Comment 16

[Marco Castelluccio [:marco]]

Set release status flags based on info from the regressing bug 1695911