Closed Bug 1722044 Opened 5 months ago Closed 4 months ago

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

Categories

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

Firefox 90
defect

Tracking

()

RESOLVED FIXED
92 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox-esr91 --- fixed
firefox91 --- wontfix
firefox92 --- fixed
firefox93 --- fixed
firefox94 --- fixed
firefox95 --- fixed

People

(Reporter: smonsarr.junk, Assigned: ngogge)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [domsecurity-active])

Attachments

(1 file)

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.

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.

Component: Untriaged → DOM: Networking
Product: Firefox → Core
Component: DOM: Networking → DOM: Security
Flags: needinfo?(ngogge)
Assignee: nobody → ngogge
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(ngogge)

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?

Flags: needinfo?(annevk)
Blocks: 1695911
Severity: -- → S3
Priority: -- → P1
Whiteboard: [domsecurity-active]

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

Flags: needinfo?(annevk)

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?

Flags: needinfo?(smonsarr.junk)

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).

See Also: → 1722703

See Sylvain's comment.

Flags: needinfo?(smonsarr.junk)
Pushed by mozilla@christophkerschbaumer.com:
https://hg.mozilla.org/integration/autoland/rev/c9fb00a913c9
Consider loads from external applications as user triggered. r=ckerschb,annevk
Status: ASSIGNED → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → 92 Branch
Regressed by: 1695911

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
Attachment #9233290 - Flags: approval-mozilla-esr91?

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

approved for 91.1esr

Attachment #9233290 - Flags: approval-mozilla-esr91? → approval-mozilla-esr91+

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.

(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.

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

You need to log in before you can comment on or make changes to this bug.