1817980 - Firefox not sending original Authorization header when fetch follows a redirect to the same origin

Status: RESOLVED FIXED

(Core :: DOM: Networking, defect, P2)

Description

[rob]

The fix to https://bugzilla.mozilla.org/show_bug.cgi?id=1802086 means that when fetch() follows a redirection to the same origin as the original request it drops the Authorization header.

e.g.:

fetch("https://firefox-redirect-issue.wiremockapi.cloud/redirect", {
  "headers": {
    "Authorization": "Token foo"
  }
});

gets a 302 with Location: https://firefox-redirect-issue.wiremockapi.cloud/authorized which is the same origin (https://firefox-redirect-issue.wiremockapi.cloud) as the original request.

The request to https://firefox-redirect-issue.wiremockapi.cloud/authorized is made without an Authorization header.

This breaks our website, which relies on a redirect maintaining that header.

Comment 1

[rob]

For reference this is not an issue on Chrome Version 110.0.5481.100 (Official Build) (arm64) or Safari Version 16.2 (18614.3.7.1.5)

Comment 2

[rob]

This is also not an issue in Chrome Version 112.0.5609.0 (Official Build) canary (arm64)

Comment 3

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

I think this should have been ReferrerInfo::IsCrossOriginRequest(aNewChannel);

https://searchfox.org/mozilla-central/rev/d85572c1963f72e8bef2787d900e0a8ffd8e6728/dom/fetch/FetchDriver.cpp#1537

skipAuthHeader = ReferrerInfo::IsCrossOriginRequest(oldHttpChannel);

Comment 4

[rob]

I've read the Priority Definitions and the Triage for Bugzilla page; it's not clear to me what "Fix in the next release cycle or the following (nightly + 1 or nightly + 2)". Does that mean it will be fixed in 111.0? Or only in 112.0?

Comment 5

[rob]

Also not an issue in Safari Release 163 (Safari 16.4, WebKit 18615.1.18.100.1)

Comment 6

[Sunil Mayya]

We can disable this feature using the following pref:

network.fetch.redirect.stripAuthHeader = false
network.http.redirect.stripAuthHeader = false.

I tested with the above pref and it works.

We will try to provide a fix by this week, else release patch with the above pref to disabled

Comment 7

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

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

Comment 8

[Sunil Mayya]

I have investigated the problem further.
We are stripping auth headers because we treating the request as cross-origin.
We treat this request as cross-origin due to different schemes for the urls here

Internally we are treating this as navigating from about:newtab to https://firefox-redirect-issue.wiremockapi.cloud/authorized

Additionally, I observe the same behavior with chrome.

I noticed that if we send the fetch request from console from https://firefox-redirect-issue.wiremockapi.cloud/ we do not have this issue for Firefox and Chrome.

Rob: Could you please confirm how you got it working in Chrome?

I did the following:

1. Open new tab in chrome
2. Open dev tools and send the fetch request mentioned in the description

I did not get response for the initial request itself. But this was not the case when I load https://firefox-redirect-issue.wiremockapi.cloud/ and send the fetch request

Comment 9

[rob]

I did the following:

• Navigated to https://example.com
• Opened the developer tools
• Entered the following into the console:

fetch("https://firefox-redirect-issue.wiremockapi.cloud/redirect", {
  "headers": {
    "Authorization": "Token foo"
  }
});

• Opened the Network tab
• Examined the requests and responses - the request to https://firefox-redirect-issue.wiremockapi.cloud/authorized had a request header Authorization: Token foo, a response status of 200 and a response body Redirect sent Authorization: Token foo

Comment 10

[rob]

You can see a screen recording here:
https://drive.google.com/file/d/1HZ3A5Jq9L7-XvABrZGhkozRjXsbJ2r2M/view?usp=sharing

Comment 11

[Sunil Mayya]

Thanks Rob.

Looks like Chrome hasn't implemented this feature yet.
https://bugs.chromium.org/p/chromium/issues/detail?id=1393520

I will check and confirm what should be the expected behavior in this case.

Comment 12

[rob]

Surely "cross-origin redirects" in this context means a redirect to a different origin to the original request, not just to a different origin to the current page?

I can't see the security issue in repeating an Authorization header to an origin to which it has already been explicitly sent in the same conversation.

As implemented in Firefox this will break any SPA using Bearer or Token authorization to an API that uses redirects, which is surely thousands of them?

Comment 13

[Sunil Mayya]

The problem is that the api
ReferrerInfo::IsCrossOriginRequest(channel) compares channel uri (https://firefox-redirect-issue.wiremockapi.cloud/authorized) with the loading principal uri(example.com). Hence, we treat this request as cross-origin.

I replaced with nsContentUtils::GetSecurityManager()->CheckSameOriginURI to determine if the request was cross-origin and it fixed our problem.

I will run few more tests and check with the security team about its implications.

Comment 14

[Sunil Mayya]

Attachment: Bug 1817980 - replace ReferrerInfo::IsCrossOriginRequest with nsScriptSecurityManager::CheckSameOriginURI for determining cross-origin redirects. r=#necko,valentin,smaug

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/daf70dc1a75a
replace ReferrerInfo::IsCrossOriginRequest with nsScriptSecurityManager::CheckSameOriginURI for determining cross-origin redirects. r=necko-reviewers,valentin

Comment 16

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/38739 for changes under testing/web-platform/tests

Comment 17

[Marian-Vasile Laza]

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

Comment 18

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 19

[Sunil Mayya]

Comment on attachment 9319643 [details]
Bug 1817980 - replace ReferrerInfo::IsCrossOriginRequest with nsScriptSecurityManager::CheckSameOriginURI for determining cross-origin redirects. r=#necko,valentin,smaug

Beta/Release Uplift Approval Request

• User impact if declined: This will break any SPA using Bearer or Token authorization to an API that uses redirects.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The change modifies an existing check for determination if the redirection is cross origin or not for stripping the authentication header.
  The feature in general has a pref to disable the behavior
• String changes made/needed:
• Is Android affected?: Yes

Comment 20

[Donal Meehan [:dmeehan]]

Comment on attachment 9319643 [details]
Bug 1817980 - replace ReferrerInfo::IsCrossOriginRequest with nsScriptSecurityManager::CheckSameOriginURI for determining cross-origin redirects. r=#necko,valentin,smaug

Approved for 111.0b8

Comment 21

[Donal Meehan [:dmeehan]]

https://hg.mozilla.org/releases/mozilla-beta/rev/485b55ab6154