Skip to content
This repository has been archived by the owner on Jul 31, 2024. It is now read-only.

Check session fails on iphone Chrome due to foreign PostMessage #4051

Closed
jonyeezs opened this issue Feb 5, 2020 · 11 comments
Closed

Check session fails on iphone Chrome due to foreign PostMessage #4051

jonyeezs opened this issue Feb 5, 2020 · 11 comments
Assignees

Comments

@jonyeezs
Copy link

jonyeezs commented Feb 5, 2020

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
Copy link
Author

jonyeezs commented Feb 5, 2020

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
Copy link
Author

jonyeezs commented Feb 5, 2020

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
Copy link
Author

jonyeezs commented Feb 5, 2020

@brockallen
Copy link
Member

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

@jonyeezs
Copy link
Author

jonyeezs commented Feb 5, 2020

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
Copy link
Author

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
Copy link
Member

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.

@brockallen brockallen added this to the 3.1.1 milestone Feb 15, 2020
@jonyeezs
Copy link
Author

jonyeezs commented Feb 16, 2020 via email

@Roach6996
Copy link

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

@brockallen
Copy link
Member

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

brockallen added a commit that referenced this issue Sep 9, 2020
…check_session

add more defensive check on check session endpoint  #4051
@leastprivilege leastprivilege removed this from the 4.1.0 milestone Sep 14, 2020
@github-actions
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 26, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants