Security flaw when creating new user and using reset link

Here is what happens (GitLab 7.13.3 on Debian 8):

1.) I log on to my GitLab server as administrator.

2.) I create a new user and GitLab states: "Reset link will be generated and sent to the user. User will be forced to set the password on first sign in."

3.) I click "Create User" and an email with the reset link is generated and sent to the new user.

4.) I close the browser tab (without logging out from my GitLab server as administrator!).

5.) As the new user (on the same computer that I used as GitLab administrator before) I click on the reset link I received in the GitLab email.

6.) GitLab opens the administrator account and tells me "You are already signed in." (as administrator)

So by clicking the reset link as a new user I end up in the (open) GitLab admin's account. Despite the fact that this a rare combination of events (GitLab admin forgets to log out and new user is using the same computer as the GitLab admin before to reset the password) this should not happen.

Many thanks!

/cc @sytses @jacobvosmaer

This has nothing to do with the reset link. You click a gitlab link in an email, your email client decides to open it in a browser which has a valid gitlab session, and a page loads based on your gitlab session (i.e. with your gitlab admin account).

What else could we expect to happen?

Well, I would have expected it will create/open the session of the particular GitLab user (the one who received the reset link) but not use any GitLab session that happens to be open in that moment.

I find the current behavior less surprising, but maybe that is just me.

@allspatial do you see a security angle to this?

Hi Jacob, As I mentioned, the situation in which this occurs is very rare, so probably it's not really an issue. If an admin would forget to log out and then the reset link of a non-admin user will open that admin's session the user could do quite some damage. On the other hand it is the admin's own fault if he forgets to log out properly. So I guess we can close that issue.

I still don't understand the security problem here... Is the reset link applied to the admin account (i.e., the admin password is reset)?

I will try to be more precise: Let's say a user "michael" was created by the GitLab admin and received an email with a reset link. User "michael" clicks that link and ends up in the open session of the GitLab admin (message "You are already signed in") instead of being pointed to a page where he ("michael") should set his password. (When "michael" ends up in the GitLab admin session he is not asked to reset the password, he sees the Dashboard page and can then start deleting users, projects, etc.)

Again, this happens only if GitLab admin and "michael" use the same computer (e.g. GitLab admin at 10:00 am and "michael" one hour later) and GitLab admin forgot to log out from GitLab. Still I would expect that some verification happens comparing the username from the reset request with the username of a potentially open GitLab session so that "michael" is not pointed to the GitLab admin session.

Wouldn't this same thing happen if the user simply opened the browser and navigated to the GitLab installation without clicking any reset link?

Hi Drew, yes it would happen and in this case expected because it is not known at this point who navigated to the GitLab url and so the open session is loaded (if any). The one and only concern I have is the "reset link" feature where a defined user receives a specific link to set/reset his password and by clicking this link he might end up in the open session/account of another user. This is not what I would expect, neither from a security point of view nor from a "user experience" point of view. However, I understood that most of you see this as an expected behavior, so likely it is. Thus, please feel free to close this issue or let me know if you want me to close it.

The one and only concern I have is the "reset link" feature where a defined user receives a specific link to set/reset his password and by clicking this link he might end up in the open session/account of another user.

Only if the user clicking on that link is in the same browser on the same workstation, logged in under the same (OS) user account that the admin user was logged in on and the admin user hasn't ended their session. I am not sure how this is gitlab specific, if you login to a website that stores session information, close the browser, then someone else opens the same browser under the same user session on the same workstation, this is the expected result.

What work process lead to this? I am assuming you logged on to gitlab from a user's workstation as administrator to set them up an account, you forgot to logout and they then used the link in email to browse to gitlab, at which point it detected your existing session in their browser and logged them in?

Yes, it is as you described. Thanks to everyone for the help and clarification!

Status changed to closed

mentioned in merge request !14785