1620913 - Some SSO authentication that only FireFox on windows 2012 cannot pass

Status: VERIFIED INVALID

(Core :: Networking: Cookies, defect)

Description

[Zhang Jie]

Attachment: Archive.zip

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_3) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.5 Safari/605.1.15

Steps to reproduce:

Try to login a internal system with SSO configured

Actual results:

SSO Authentication failed

Expected results:

Don't know why, but only FireFox+Windows2012 failed. Firefox +Mac and FireFox+windows10 are all other browsers are fine.

fire fox version: 73.0.1 (64-bit)
Windows Server 2012 R2 Standard

Comment 1

[:Gijs (he/him)]

Why is this filed as a security vulnerability? It looks like it's just a bug report, not a vulnerability...

Comment 2

[Zhang Jie]

Oh, I am sorry that I may select wrong option of this. It is not a security vulnerability, b ut a bug report.

Comment 3

[Zhang Jie]

More information:
OIDC config responds with

Set-Cookie: WASOidcStatep433235165=001583735794798MGf9NuOcS30nVOXU1CtV61jFa3aIhmbn/F6tYn+TtmU=; Expires=Mon, 09 Mar 2020 06:43:34 GMT; Path=/; Secure; HttpOnly
to the initial request to /navigator.

Then, there is interaction between browser and UMS and when UMS sends the browser back to ICN, this cookie is not sent by the browser. It is lost during redirections.

Only happens with Firefox+windows 2012.

Comment 4

[:Gijs (he/him)]

Alright, removing the sec-sensitive classifier and moving over to networking who can hopefully figure out from the har files in the attached zip what exactly is going wrong.

Comment 5

[Michal Novotny [:michal]]

Honza, can you have a look?

Comment 6

[Honza Bambas (:mayhemer)]

Zhang, I will ask you for an http log that can reveal what is going on. Both a working case and a broken case would be best, so that we can compare what is expected and what is broken.

See https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging.

Thanks.

Comment 7

[Zhang Jie]

/Users/calvin/temp/firefox/notworking.zip
/Users/calvin/temp/firefox/working.zip

Comment 8

[Zhang Jie]

Attachment: notworking.zip

Comment 9

[Zhang Jie]

Attachment: working.zip

Comment 10

[Zhang Jie]

Hi Honza,
Thank you. Here are 2 logs for working(Mac+Firefox 73.0.1 64bit) and not working(windows2012 + Firefox 73.0.1 64bit) environments.

Comment 11

[Honza Bambas (:mayhemer)]

Thanks for the logs.

In the notworking case I can see the server answers with WWW-Authenticate: Bearer realm="oauth", which we don't handle, never were and don't plan to. In the working case, I see no response requiring authentication at all.

It would be good to capture the logs from the very start using e.g. command line args and resubmit, both working and not working case.

This could be a server misconfiguration or a cookie issue. But so far it's too early to make a conclusion.

Comment 12

[Honza Bambas (:mayhemer)]

And it would also be good to provide a little more details about what URL you navigate and see it fail, and in what way exactly. To be honest, "SSO Authentication failed" is too vague to decide on what to actually look for.

Comment 13

[Zhang Jie]

Attachment: working-2.zip

Comment 14

[Zhang Jie]

Attachment: notworking-2.zip

Comment 15

[Zhang Jie]

Hi Honza,

Thank you. The progress is like the request/response in Archive.zip.

1. Access https://navigator-navi.9.30.253.104.nip.io/navigator/
2. The liberty server found it has no authenticated, then redirect to
   https://ums.9.30.118.65.nip.io/oidc/endpoint/ums/authorize to check authentication
3. redirect to https://ums.9.30.118.65.nip.io/ums/login to input user name and password.
4. Then it go to https://ums.9.30.118.65.nip.io/ums/j_security_check to check
5. After check go to https://ums.9.30.118.65.nip.io/oidc/endpoint/ums/authorize
6. redirect to https://icn.9.30.118.65.nip.io/oidcclient/redirect/navigator with authenticate cookies
7. redirect back to https://navigator-navi.9.30.253.104.nip.io/navigator/

In working env (windows 10+FireFox 74 64bit), step 6 has a cookie set before named like: WASOidcStatep433235165
in not working env (windows 2012+FireFox74 64bit), step6 does not have that cookie. That make step7 return 401 code (by the web application server for not authenticated)

Comment 16

[Honza Bambas (:mayhemer)]

Moving to a different component. This then a cookie issue. I still have to take a look at the logs, tho.

Comment 17

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

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Comment 18

[Andrea Marchesini [:baku]]

Honza, do you think it's related to cookie sameSite=lax by default?

Comment 19

[Honza Bambas (:mayhemer)]

(In reply to Zhang Jie from comment #15)

Hi Honza,

Thank you. The progress is like the request/response in Archive.zip.

1. Access https://navigator-navi.9.30.253.104.nip.io/navigator/
2. The liberty server found it has no authenticated, then redirect to
   https://ums.9.30.118.65.nip.io/oidc/endpoint/ums/authorize to check authentication
3. redirect to https://ums.9.30.118.65.nip.io/ums/login to input user name and password.
4. Then it go to https://ums.9.30.118.65.nip.io/ums/j_security_check to check
5. After check go to https://ums.9.30.118.65.nip.io/oidc/endpoint/ums/authorize
6. redirect to https://icn.9.30.118.65.nip.io/oidcclient/redirect/navigator with authenticate cookies
7. redirect back to https://navigator-navi.9.30.253.104.nip.io/navigator/

In working env (windows 10+FireFox 74 64bit), step 6 has a cookie set before named like: WASOidcStatep433235165
in not working env (windows 2012+FireFox74 64bit), step6 does not have that cookie. That make step7 return 401 code (by the web application server for not authenticated)

In the logs I can see:

• the response to /navigator/ has Set-Cookie: WASOidcStaten*=... in both the working and non-working case.
• in the working case we send this cookie along with the /oidcclient/redirect/WocISsaynmxpPKsIOQXR?code=BATB2rRXhosTgqFmKhk6GUFQBy2pi4&state=001583985615536PyefPEzNj request; in the non-working case we don't

I will ask you a favor once more: can you please rerun the log capture once more with added cookie:5 to the list of modules in MOZ_LOG. I suspect we don't store the cookie from some reason. W/o that info added to the log it's hard to find out why.

Comment 20

[Zhang Jie]

Attachment: notworking-cookie.zip.001

Comment 21

[Zhang Jie]

Attachment: notworking-cookie.zip.002

Comment 22

[Andrea Marchesini [:baku]]

In nightly we are experimenting with a feature called "cookies sameSite=lax by default". Any cookie without a sameSite attribute value will be treated as sameSite=lax. If you use nightly, you should see messages in the console log about this.

We are working on a proper documentation page, but in the meantime, I suggest to read: https://web.dev/samesite-cookies-explained/
In your case, probably the fix is to use sameSite=none.

Comment 23

[Zhang Jie]

Attachment: Screen Shot 2020-03-23 at 17.12.06.png

Comment 24

[Zhang Jie]

Hi Andrea,

Thank you for helping on this.

The thing is we use the very same FireFox version, just on different OSs (windows 10 works, windows2012 does not). Chrome latest versions works. That seems no need the application to do the fix.

And I check the the Firefox about:config for work/not-work env, they are the same. Attach the screenshot.

Comment 25

[:Gijs (he/him)]

Honza, do the cookie logs help clarify what's going on here?

Comment 26

[Honza Bambas (:mayhemer)]

2020-03-19 10:02:58.608000 UTC - [Parent 296: Main Thread]: W/cookie ===== COOKIE NOT ACCEPTED =====
2020-03-19 10:02:58.608000 UTC - [Parent 296: Main Thread]: W/cookie request URL: https://navigator-navi.9.30.253.104.nip.io/navigator/
2020-03-19 10:02:58.608000 UTC - [Parent 296: Main Thread]: W/cookie cookie string: WASOidcStatep974598291=001584583379578PeAw9Nmh7ztAWj6s41TrT91v9skuE2QIr3OJyvmcxRs=; Expires=Thu, 19 Mar 2020 02:09:59 GMT; Path=/; Secure; HttpOnly
8a67fb3b692b75de89e6389bc2117658=d6549ceec95676d8d65313ad32cb2d05; path=/; HttpOnly; Secure
2020-03-19 10:02:58.608000 UTC - [Parent 296: Main Thread]: W/cookie current time: Thu Mar 19 10:02:58 2020 GMT
2020-03-19 10:02:58.608000 UTC - [Parent 296: Main Thread]: W/cookie rejected because cookie has already expired
2020-03-19 10:02:58.608000 UTC - [Parent 296: Main Thread]: W/cookie 

INVALID?

Comment 27

[Zhang Jie]

Thank you for helping on this issue!! I also learned how to investigate it.

Comment 28

[Zhang Jie]

in working env, the cookie time is:
Set-Cookie: WASOidcCode=""; Expires=Thu, 01 Dec 1994 16:00:00 GMT; Path=/; HttpOnly

Comment 29

[Zhang Jie]

and WASOidcStaten1611106398=""; Expires=Thu, 01 Dec 1994 16:00:00 GMT; Path=/; HttpOnly

Comment 30

[Zhang Jie]

Oh, that is the real set part:

2020-03-12 04:00:15.427000 UTC - [Parent 18308: Socket Thread]: E/nsHttp Set-Cookie: WASOidcStaten1611106398=0015839856155368JCLK/NTG/nlnb7F/AARvLQ5WfwgmZw5RJN1Not13OA=; Expires=Thu, 12 Mar 2020 04:07:15 GMT; Path=/; Secure; HttpOnly