Check session fails on iphone Chrome due to foreign PostMessage

[jonyeezs]

We can only help you if you are on the latest version. Either use the latest 2.x or 3.x
Currently on version 2.5.4 (We are unable to migrate to 3 at this point in time - but will soon).

This issue is ❗critical❗ to our operation.

Unable to successfully complete check session on iPhone 12 and later Chrome.
Works on Safari and other browsers.

Issue / Steps to reproduce the problem

Tooling:

• Front-end: Angular SPA using angular-oauth2-oidc using implicit flow with with checksession enabled
• Back-end: IdentityServer4 with custom authentication pages (ie sign in and sign up).

Steps

• Only an issue on iPhone 12 and later for Chrome

1. As mentioned in tooling. Setup an environment for implicit flow.
2. go to the app, which takes you back to the identity sign in page.
3. Implicit flow would be successful.
4. When checksession is happening - calling the oidc checksession endpoint
5. The checksession iFrame throws error and we get a session_error on our front end
6. Which we then log out the user.

The session_error event is a valid event where we would want the user to try logging in again or error them out. But what is failing is that the whole system works EXCEPT a foreign message gets sent to the iframe FROM the **parent(!)**😱

Relevant parts of the log file

For testing purposes I recreated the checksession html page with our own logging to see what's happening.

This is what we get:

• Exception caught

  message.lastIndexOf is not a function. (In 'message.lastIndexOf(" ")', 'message.lastIndexOf' is 
  undefined)
  

• The origin of the message: https://<the-parent-url-masked-for-reasons>.com
• And the message (ie: event.data)

{
   "type":"org.chromium.encryptedMessage",
   "message_payload":{
      "iv":"XPdQHgg8VcGTkp8C",
      "payload":"mSxSiVDrKQDI/nYaRFVrKFminCbYaq53kV45SCm4uPZOzedruAu6v/37NsxgNwsWrj9eSNQ/"
   },
   "function_payload":{
      "iv":"KeujU9n5njIu3snB",
      "payload":"WiYGGD14PeiFArp0ZlndAf4UhjMrjq0J3zy6y1LA/4dJFg3JkrjenxpNJ32yehj5zngvvS0LT4gLWx5rEgoerAASQZ9vVgrHNbby07RUxA=="
   },
   "target_frame_id":"a7b52b0a32fca0e78e174b4ab816eeb6"
}

[jonyeezs]

iOS chromium implementation on iframe setup also expects objects to be sent a iframe https://github.com/chromium/chromium/blob/master/ios/web/js_messaging/resources/setup_frame.js.

And there is this SO post: https://stackoverflow.com/questions/54079756/internal-chromium-postmessage-event

[jonyeezs]

Suggestion we have is to ensure that we have defensive code to enforce the contract of event.data to be a string and only allow that to go through to calculateSessionStateResult.

Proposed on CheckSessionResult.cs

                if (window === e.source) {
                    // ignore browser extensions that are sending messages.
                    return;
                }
                
                if (typeof e.data !== "string") {
                    return;
                }

[jonyeezs]

Couple providers that do this:

• KEYCLOAK-6534 Check for string in receiveMessage in session iframe keycloak/keycloak#4995
• panva/node-oidc-provider@6c27f10

[brockallen]

Do you know why/who is sending the invalid request in the first place?

[jonyeezs]

The origin is from our parent website (hosting the iframe).

But we don't have any other code sending messages to the checksession iframe.

Plus it only happens on iOS chrome.

Why it is sending? No idea. There's a SO post i mentioned above with people equally as confused.

Could not find anything official from the chrome team.

[jonyeezs]

Has there been any progress on this? Sorry I couldn't provide more root analysis. I can't be the only one who has encountered this issue??

[brockallen]

I've never heard of this issue before, but your proposed change is benign enough I don't see why we can't include it in the next release.

[jonyeezs]

Very curious. Do you have an environment with a SPA and checkSession enabled? Wondering if others experience it on iPhone chrome as well. The stackoverflow post kinda affirms my position. And it only happens on that browser. All other works. Must be browser specific.

…

On Sun, 16 Feb 2020, 12:49 am Brock Allen, ***@***.***> wrote: I've never heard of this issue before, but your proposed change is benign enough I don't see why we can't include it in the next release. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4051?email_source=notifications&email_token=ACS4BBR2JVSM45J6FMSMVCLRC76IZA5CNFSM4KQCYOW2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3MIBY#issuecomment-586597383>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACS4BBTRFKQ5OHNQI5B2VVTRC76IZANCNFSM4KQCYOWQ> .

[Roach6996]

I am facing similar issue.
It breaks only on chrome and works on safari (iOs)

[brockallen]

Sorry that this slipped thru the cracks and I didn't get to it until now. PR submitted.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.