1679318 - SameSite noneRequiresSecure = true breaks logging into myplan.johnhancock.com

Status: RESOLVED WONTFIX

(Web Compatibility :: Site Reports, defect)

Description

[Asif Youssuff]

Steps to reproduce:

1. Navigate to https://myplan.johnhancock.com/login
2. Type in username/password, click Login

What happens:

Form submits and page appears to reload.

I see this in the console:

Loading failed for the <script> with source “https://johnhancockfinancialservices.sc.omtrdc.net/b/ss/jhfs…2.22.0-LAWA/s58100189518704?AQB=1&ndh=1&pf=1&callback=s_c_il[1].doPostbacks&et=1&t=25%2F10%2F2020%2016%3A6%3A18%203%20300&d.&nsid=0&jsonv=1&.d&mid=20375281222620687980991451090888831279&aamlh=7&ce=UTF-8&pageName=MLN%3AJHRPS%20%7C%20Login&g=https%3A%2F%2Fmyplan.johnhancock.com%2Flogin&c.&di_launch_lib_ms=312.00&di_session_id_ms=442.00&di_session_id=di-311589-ACBA9DDDFAD8AE89F58CAA134257422E80&.c&cc=USD&events=event2&pe=lnk_o&pev2=link%20clicked&s=1366x768&c=24&j=1.6&v=N&k=Y&bw=1366&bh=414&mcorgid=369B27E253DB0DB20A490D4E%40AdobeOrg&lrt=1507&AQE=1”. login:1:1
Request to access cookie or storage on “https://bam-cell.nr-data.net/events/1/2e7ea17242?a=555111956…D%3D&rst=23187&ck=1&ref=https://myplan.johnhancock.com/login” was blocked because it came from a tracker and content blocking is enabled.

Request to access cookie or storage on “<URL>” was blocked because it came from a tracker and content blocking is enabled. 2

Expected result:

I am taken to my financial information.

17:22.57 INFO: Narrowed integration regression window from [28a2fba7, 150b8347] (4 builds) to [a14a131c, 150b8347] (2 builds) (~1 steps left)
17:22.57 INFO: No more integration revisions, bisection finished.
17:22.57 INFO: Last good revision: a14a131ca73171c6aab469abefb9db79120e056a
17:22.57 INFO: First bad revision: 150b8347d28f8a05bddd6cd9ea4b7851490639a1
17:22.59 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a14a131ca73171c6aab469abefb9db79120e056a&tochange=150b8347d28f8a05bddd6cd9ea4b7851490639a1

Comment 1

[Karl Dubost💡 :karlcow]

Needs Triage.

Comment 2

[Raul Bucata]

We appreciate your report. For this issue, unfortunately, a special account is needed to sign in. Test account creation requires a valid Social Security Number

Having no valid sign-in credentials, we are not able to move forward with this issue.
If more information is provided (test account credentials can only be provided by mail for security purposes, as the comments here are made public,/ attach logs/errors), in-depth testing can be performed, so please feel free to reopen or comment on the issue and we'll have a thorough look at it.

Suggestion: Try clearing cache/data/cookies, disable Ad-blocker (if available), or use a clean profile, and check again? Also, have the required cookies have been accepted for this page? Also, is the issue reproducible on your side using the latest build of Firefox Nightly?

Comment 3

[Asif Youssuff]

Raul, unfortunately, I continue to see the issue and the login requires two factor authentication (I am sent an email when an attempt to login is made with a code).

If someone is willing to diagnose this during working hours in New York, I'd be happy to share my credentials (along with sending over the second factor). I am available on Matrix if this makes sense. If there is a better way to go about this (logging, etc.), I am also happy to try that as well.

Comment 4

[Karl Dubost💡 :karlcow]

Maybe Thomas can help here.

Comment 5

[Thomas Wisniewski [:twisniewski]]

I'm chatting with the ETP team today to figure out who is best to deal with this, thanks for pinging me Karl.

Comment 6

[Thomas Wisniewski [:twisniewski]]

Just to confirm, Asif just let me know that with laxByDefault=false on a fresh profile, the login does work.

Next we'll try to compare whether Chrome and Firefox are treating any of the cookies with different samesite strictness.

Comment 7

[Raul Bucata]

Any updates on this Tom, as an account is still needed on my part and account creation requires a valid SSN?

Comment 8

[Thomas Wisniewski [:twisniewski]]

I think Asif has since lost access to his account, but we handed off all the information we could find directly to Ben before then. Hopefully he has enough to go on when he has time to revisit this issue. Ben, any updates?

Comment 9

[Benjamin VanderSloot [:bvandersloot]]

I'm curious if the problem persists on FX96 because SameSite=Lax was just made default. Other than that I have no updates.

Comment 10

[Benjamin VanderSloot [:bvandersloot]]

After some chat in Matrix, Asif and I discovered that this bug is resolved with a user agent switch to Chrome. I suspect the site is handing out different cookie flags for Chrome. We should reach out to get us the same treatment.

Also, this affects release with FX96.

Comment 11

[[e-mail]]

The inability to log in to https://myplan.johnhancock.com/login continues. My customer service agent at John Hancock confirmed that it is a Firefox browser issue and that John Hancock has attempted to contact Mozilla about a fix but has so far been unsuccessful in getting the problem resolved. I do not know if it is because Mozilla has failed to respond, but I got that impression. The problem exists currently in Firefox version 96.0.1. The agent suggested using Microsoft Edge or Google Chrome to log in, which was not what I wanted to hear...

Comment 12

[Daniel Veditz [:dveditz]]

Alan: unfortunately, despite what the customer service agent (not a web developer) said, this is a John Hancock problem. Chrome and Edge "work" because the site uses the correct code, and they serve different, broken code to Firefox.

If you fool their site into thinking you're using Chrome it appears the site will work according to comment 10. One way to do this is to use an add-on to spoof your "User-Agent" string. One that is currently recommended by our Add-ons site (look for the badge) is https://addons.mozilla.org/en-US/firefox/addon/user-agent-string-switcher/

CAUTION: although this will fix some sites, it will break some others that do need to treat Firefox and Chrome differently. I recommend changing the user-agent to Chrome in order to log in, and then reset it back to the default right after so you don't forget and get mysteriously broken sites later.

There is a more manual way to change the user-agent that doesn't involve an add-on, but it's more cumbersome. If you'd prefer that please ask for help at https://support.mozilla.org/

Comment 13

[[e-mail]]

Thanks Daniel!

Comment 14

[Ksenia Berezina [:ksenia]]

Until this is addressed by the website, we can ship a temporary UA override in Firefox as the site seems pretty popular. I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1751329 for that.

Comment 15

[Dianna Smith [:diannaS]]

marking as disabled for fx96 since we set sameSite.laxByDefault and sameSite.noneRequiresSecure to false via a pref flip

Comment 16

[Oana Arbuzov [:oanaarbuzov]]

Asif does the issue still reproduce on your side?

Comment 17

[Asif Youssuff]

(In reply to Oana Arbuzov [:oanaarbuzov] from comment #16)

Asif does the issue still reproduce on your side?

Oana, this issue continues to be reproducible on the latest Nightly with a fresh profile. I was able to login normally using GNOME Web.

Comment 18

[Tom Schuster (MoCo)]

Do you see any new console messages? We added more logging since two years ago.

Comment 19

[Asif Youssuff]

I just tried this again this morning, and it actually worked this time. Perhaps JH has actually fixed this. I'm going to mark this WFM.

Comment 20

[Asif Youssuff]

Okay - it works in release, but not in Nightly.

Console log from Nightly:

Cookie “s_sq” has “SameSite” policy set to “Lax” because it is missing a “SameSite” attribute, and “SameSite=Lax” is the default value for this attribute. AppMeasurement.min.js:2:1763
Loading failed for the <script> with source “https://johnhancockfinancialservices.sc.omtrdc.net/b/ss/jhfswamjhreupeprod/10/JS-2.22.0-LAWA/s31796057750610?AQB=1&ndh=1&pf=1&callback=s_c_il[1].doPostbacks&et=1&t=8%2F6%2F2022%2013%3A11%3A27%205%20240&d.&nsid=0&jsonv=1&.d&mid=09335038968708836833827963107779218687&aamlh=7&ce=UTF-8&pageName=MLN%3ALog%20in%20to%20your%20John%20Hancock%20retirement%20account&g=https%3A%2F%2Fmyplan.johnhancock.com%2Flogin&c.&di_launch_lib_ms=2.00&di_session_id_ms=0.00&di_session_id=di-311589-D7DB84D78E32AE8F459CAA13B588B320A9&.c&cc=USD&events=event2&pe=lnk_o&pev2=link%20clicked&s=1920x1080&c=32&j=1.6&v=N&k=Y&bw=1280&bh=637&mcorgid=369B27E253DB0DB20A490D4E%40AdobeOrg&lrt=211&AQE=1”. login:1:1
Ignoring unsupported entryTypes: largest-contentful-paint. login:11:19666
No valid entryTypes; aborting registration. login:11:19666
Ignoring unsupported entryTypes: layout-shift. login:11:19762
Cookie “s_upe” rejected because it has the “SameSite=None” attribute but is missing the “secure” attribute. 2 login
Some cookies are misusing the “SameSite“ attribute, so it won’t work as expected 19
Use of the orientation sensor is deprecated. login:11:25269
Use of the motion sensor is deprecated. login:11:25269
*****THIS IS WORKING***** launch-EN87fc0302002640dfb05c0ca314d251cb.min.js:8:8769
Request to access cookie or storage on “https://bam.nr-data.net/1/2e7ea17242?a=555111956&v=1216.487a282&to=ZgcGZBZQWRdZUExeXV9NKWYnHmQNTFZbWEBUIQteEENYCFRWShh7XwYBSA%3D%3D&rst=924&ck=1&ref=https://myplan.johnhancock.com/login&ap=79&be=594&fe=888&dc=767&af=err,xhr,stn,ins&perf=%7B%22timing%22:%7B%22of%22:1657300287182,%22n%22:0,%22u%22:568,%22r%22:3,%22ue%22:574,%22re%22:259,%22f%22:259,%22dn%22:259,%22dne%22:259,%22c%22:259,%22s%22:259,%22ce%22:259,%22rq%22:261,%22rp%22:558,%22rpe%22:559,%22dl%22:567,%22di%22:753,%22ds%22:766,%22de%22:768,%22dc%22:887,%22l%22:887,%22le%22:895%7D,%22navigation%22:%7B%22rc%22:1%7D%7D&fcp=674&jsonp=NREUM.setToken” was blocked because it came from a tracker and content blocking is enabled.

Comment 21

[Tom Schuster (MoCo)]

Thank you!

Could you do me a favor and check if it still works after setting network.cookie.sameSite.laxByDefault to false in Nightly?

This following error message has me concerned that the actual breakage might be related to nonRequiresSecure and not laxByDefault.

Cookie “s_upe” rejected because it has the “SameSite=None” attribute but is missing the “secure” attribute.

Comment 22

[Daniel Veditz [:dveditz]]

Presumably the main breakage came from the inability to load the script, and that's more likely due to the s_sq cookie. In theory Chrome would also reject s_upe if it was set as SameSite=None without the secure attribute. Would a site only sometimes use the secure attribute depending on what browser was being used? It would take extra code to intentionally do that which is hard to believe, but we've seen sites do things like that so it's certainly possible.

Use of the orientation sensor is deprecated. login:11:25269
Use of the motion sensor is deprecated. login:11:25269

Love the apparent attempt to fingerprint you. I wonder what else they're poking around at that they shouldn't need for a financial site.

Comment 23

[Daniel Veditz [:dveditz]]

Makes no sense, but yes, John Hancock sends s_upe with the secure attribute to Chrome and without to Firefox.

Chrome: set-cookie: s_upe=q41qrctvoi03wu5f5nvkvald; Path=/; SameSite=None; Secure; HttpOnly
Firefox: set-cookie: s_upe=mndazlxl1fzf03q1yanr5m4l; Path=/; SameSite=None; HttpOnly

That cookie was set on the initial page load so it's not a user auth cookie, but

• it shows they're quite willing to do this bananas thing and might on some other cookie that is more involved with auth
• maybe it's some kind of anti-abuse token or API key to load otherwise-static cross-origin resources

Following up comment 21: if disabling laxByDefault in nightly doesn't fix the site, please set network.cookie.sameSite.noneRequiresSecure to false and see if the site starts working.

If turning off noneRequiresSecure fixes the login, try turning laxByDefault back on (true) and see if it works with only noneRequiresSecure disabled. Would be very nice to know if we're broken on the site for only one of them, or if either independently breaks the site.

Comment 24

[Asif Youssuff]

Sorry about the delay here, team.

Setting:

network.cookie.sameSite.laxByDefault = false
does not work.

Setting:

network.cookie.sameSite.laxByDefault = false
network.cookie.sameSite.noneRequiresSecure = false
works.

Setting:

network.cookie.sameSite.laxByDefault = true
network.cookie.sameSite.noneRequiresSecure = false
works.

Hope this helps!

Comment 25

[Tom Schuster (MoCo)]

Thanks for the confirmation!

Comment 26

[Calin Tanase]

Is the issue still reproducible for you, Asif? If so could you please test it with Enhanced Tracking Protection OFF, Standard and Strict, each on a clean profile and give us an update?

Comment 27

[Asif Youssuff]

(In reply to Calin Tanase from comment #26)

Is the issue still reproducible for you, Asif? If so could you please test it with Enhanced Tracking Protection OFF, Standard and Strict, each on a clean profile and give us an update?

Calin, sure. On Firefox Nightly, the issue is reproducible with tracking protection in all of those configurations.

Comment 28

[Calin Tanase]

Thanks for the update, Asif.

Comment 29

[Donal Meehan [:dmeehan]]

Setting 109/110 to disabled

Comment 30

[Celeste]

Since Chromium 80 (June 2020) has enforced Secure when SameSite=None, and this site has a fix but it just doesn't apply to Firefox. So I think we should enable it by default to enforce this site to apply their fix to Firefox as well. We SHOULD NOT put the security of all users at risk because of a garbage website. What's more, the maintainers of this website actually know about this problem, they just refuse to apply a fix for Firefox.

Comment 31

[Manuel Bucher [:manuel]]

We won't be shipping samesitelax by default, so all of this breakage bug can be closed: Bug 1617609