1718850 - sessionStorage is cleared when cross-origin-opener-policy (COOP) is enabled

Status: RESOLVED DUPLICATE of bug 1712961

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

Description

[lauredo+github]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36

Steps to reproduce:

1. Open a Web site with COOP set to same-origin e.g.

Cross-Origin-Opener-Policy: same-origin

2. Set a key in sessionStorage e.g.

sessionStorage.setItem('key, 'value')

3. Navigate to another Web site due to a server-side redirection (HTTP 302/303).

Note that the same can be observed using manual redirection by typing in the address bar but this one could be justified by the discussion in https://github.com/whatwg/html/issues/6356.

4. Press the back button to return to the first Web site with COOP

Check sessionStorage, it is now empty instead of containing the example 'key'.

This does not happen in Chrome or in previous versions of Firefox.

The issue is related to https://github.com/whatwg/html/issues/6356 but pertains to HTTP redirections e.g. needed for authentications using a Single Sign On provider (e.g. OpenID Connect, OAuth2, SAML, etc.).

So it is not a "manual" navigation, as mentioned in the github issue, but a server-side redirection to the SSO provider, back and forth to the initial site.

Losing sessionStorage content defeats the purpose of such SSO protocols.

Actual results:

With COOP set to same-origin, the sessionStorage is cleared after server-side redirection to another origin and then coming back to the original origin in the same tab.

Expected results:

The sessionStorage should be kept to the content initialized in the same tab before the server-side redirection.

Comment 1

[lauredo+github]

Remark for point 4): the failing case with the SSO provider is actually another server-side redirection (HTTP 302/303) to the initial Web site.

Pressing the back button is also a case of "manual" navigation which could be justified by the https://github.com/whatwg/html/issues/6356 issue.

Comment 2

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

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

Comment 3

[lauredo+github]

Further investigations with the SSO provider have shown that redirections to the SSO web site include

• javascript location.href=xxx and
• HTML meta http-equiv="Refresh"
  calls as well as HTTP 302/303 during the SSO authentication flow.

Testing the whole flow when only HTTP 303 redirections are at play, Firefox 89 does not clear the sessionStorage and keys can be retrieved, as expected.

So, it seems the behaviour is induced either by the location.href call or by the meta refresh presence.

Comment 4

[lauredo+github]

Test results on Firefox 89:

• If redirections happen with HTTP 302/303, the sessionStorage is not cleared when coming back to the initial application.

• If the redirection is performed client-side using:
  -- location.href = xxx;
  -- location.replace(xxx);
  -- location.reload();
  -- <meta http-equiv="Refresh" content="0; url=xxx>
  then the sessionStorage is cleared.

• If redirections is triggered from a server-side "Refresh" HTTP response header, the sessionStorage is cleared as well.

• If the end-user manually clicks on a link to the initial application (generated in the redirection page), the sessionStorage is cleared too.

Comment 5

[lauredo+github]

This issue is related to https://bugzilla.mozilla.org/show_bug.cgi?id=1656768 which is supposed to be fixed.

Comment 6

[Daniel Veditz [:dveditz]]

Anne: is a manual-redirect (js or meta refresh) supposed to be different from a 30x for COOP?

Comment 7

[Anne (:annevk)]

Not really. Hopefully Nika or Olli (when back) can take a look.

Comment 8

[Nika Layzell [:nika] (ni? for response)]

I haven't spent enough time looking into this to be sure, but I'm thinking that this might be related to bug 1700623, as it landed in the 90 timeframe and touched Session Storage. I'll try to put together a local STR and get a mozregression soon. Leaving my ni? up until then.

Comment 9

[Nika Layzell [:nika] (ni? for response)]

ni? :farre due to the suspected regressor of bug 1700623

Comment 10

[Andreas Farre [:farre]]

This being due to bug 1700623 sounds entirely plausible. I'll look into it.

Comment 11

[Andreas Farre [:farre]]

Attachment: Bug 1718850 - Part 1: Test that session storage is preserved over redirects. r=nika!

Comment 12

[Andreas Farre [:farre]]

I'm not sure that I understand the STR's here. I wrote up a mochitest to capture them, and indeed, if you vary the way that you return to the page that you were at before redirection, session storage preservation differs. But not due to bug 1700623 in any way I could create. So I'm apparently missing something.

I added the patch with the test, but I thought I'd reach out and ask for help. :annevk, :nika, do you see what I do wrong here?

Comment 13

[Andreas Farre [:farre]]

Actually think that I found it. We have a bug that's not introduced by bug 1700623. When we propagate the manager we make it depend on mozilla::SessionHistoryInParent(), but we should always use Session Storage in the parent.

Comment 14

[Andreas Farre [:farre]]

Attachment: Bug 1718850 - Part 2: Always propate BackgroundSessionStorageManager in the parent. r=nika!

Depends on D123191

Comment 15

[Dianna Smith [:diannaS]]

:farre are you planning on making any changes to the attached patch?

Comment 16

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Andreas is finishing his big patches around session store in https://bugzilla.mozilla.org/show_bug.cgi?id=1739450
After that work, he will be able to revisit this issue.

Comment 17

[Andreas Farre [:farre]]

This doesn't reproduce any longer. I'll spend some time to verify, but I'll close as invalid after that.

Comment 18

[Andreas Farre [:farre]]

This doesn't reproduce for me, and in any case bug 1712961 is the same issue. Closing this and keeping the intermittent (which I'll probably also close soon since that doesn't seem to reproduce any more as well).