Moodle
  1. Moodle
  2. MDL-24120

Allow admin to remain logged in after login as procedure

    Details

    • Affected Branches:
      MOODLE_20_STABLE
    • Story Points:
      20
    • Rank:
      5133

      Description

      log in as admin to moodle 2
      go to a course (home page is enough)
      from participants block, select a student and login as him/her
      do something (at least nothing) and return to your personal account
      at the end of this process, you are always logged out

        Issue Links

          Activity

          Hide
          Petr Škoda added a comment -

          yes, this is necessary for security reasons. We did not find any better way, sorry

          Show
          Petr Škoda added a comment - yes, this is necessary for security reasons. We did not find any better way, sorry
          Hide
          Andrea Bicciolo added a comment -

          Petr,
          thank you for your clarification. That's werd , anyway if it is for security and there are not better way....

          However, we could help users who know the login as function (working since the very beginning up to moodle 1.9) to avoid to be stuck and think it is a bug (like me ).

          What about warn users when they click on "login as" ? Or let the know in some other way, such as a message? or any other better way I'm sure you can think of.

          Show
          Andrea Bicciolo added a comment - Petr, thank you for your clarification. That's werd , anyway if it is for security and there are not better way.... However, we could help users who know the login as function (working since the very beginning up to moodle 1.9) to avoid to be stuck and think it is a bug (like me ). What about warn users when they click on "login as" ? Or let the know in some other way, such as a message? or any other better way I'm sure you can think of.
          Hide
          Petr Škoda added a comment -

          Yes, we could improve the loginas confirmation message. Unfortunately to make it really secure you should close and relaunch the browser.

          Show
          Petr Škoda added a comment - Yes, we could improve the loginas confirmation message. Unfortunately to make it really secure you should close and relaunch the browser.
          Hide
          Helen Foster added a comment -

          How about simply removing the Admin user link at the top right of the page, so that it only says "You are logged in as Sam Student (Logout)". Having an Admin link there too suggests that you can click on it and return to being logged in as an admin.

          Show
          Helen Foster added a comment - How about simply removing the Admin user link at the top right of the page, so that it only says "You are logged in as Sam Student (Logout)". Having an Admin link there too suggests that you can click on it and return to being logged in as an admin.
          Hide
          Petr Škoda added a comment -

          Helen: the link is useful because if you click it you get returned to the same course after login, if you click logout you go to the frontpage.

          Show
          Petr Škoda added a comment - Helen: the link is useful because if you click it you get returned to the same course after login, if you click logout you go to the frontpage.
          Hide
          Helen Foster added a comment -

          Wow, I never would have noticed that feature if you hadn't pointed it out Petr! Just wondering how useful it actually is though i.e. would an admin always want to be returned to the same course, or can we remove the feature for the sake of simplicity? Any comments from our watchers?

          Show
          Helen Foster added a comment - Wow, I never would have noticed that feature if you hadn't pointed it out Petr! Just wondering how useful it actually is though i.e. would an admin always want to be returned to the same course, or can we remove the feature for the sake of simplicity? Any comments from our watchers?
          Hide
          Andrea Bicciolo added a comment -

          No great ideas here, sorry.... I think a messages could suffice.

          Show
          Andrea Bicciolo added a comment - No great ideas here, sorry.... I think a messages could suffice.
          Hide
          Helen Foster added a comment -

          Suggestion from Bryan Dawson in http://moodle.org/mod/forum/discuss.php?d=161162:

          I think a tooltip with a message like 'Log out as other user and log back in as yourself' would explain what would happen without cluttering up the screen.

          Show
          Helen Foster added a comment - Suggestion from Bryan Dawson in http://moodle.org/mod/forum/discuss.php?d=161162: I think a tooltip with a message like 'Log out as other user and log back in as yourself' would explain what would happen without cluttering up the screen.
          Hide
          Aaron Cowell added a comment -

          I never noticed this before in my Beta and RC testing but I now see this happening on the migrated and upgraded server. This is certainly very strange behavior since 1.9+ did the user switching seemlessly. Now I use automatic login so logging back in as administrator is as simple as a finger swipe. I agree with Andrea that some sort of message could be displayed on the page after login as where you click continue alerting the administrator of being logged out when switching back to admin and/or a tooltip when hover over "admin" link at the end of the currently logged in user string. I'm going to imagin that other administrators will be reporting this as a bug when they upgrade to 2.0. Eventually it'll become the way of life once pervious versions of servers or phased out.

          What about an administrative option to relaunch browser upon user switching? As it was stated, true security would force logoff and reload browser. So if the Admin could enforce browser reload or not and obviously the browser reload would be off by default... Just a thought...

          Show
          Aaron Cowell added a comment - I never noticed this before in my Beta and RC testing but I now see this happening on the migrated and upgraded server. This is certainly very strange behavior since 1.9+ did the user switching seemlessly. Now I use automatic login so logging back in as administrator is as simple as a finger swipe. I agree with Andrea that some sort of message could be displayed on the page after login as where you click continue alerting the administrator of being logged out when switching back to admin and/or a tooltip when hover over "admin" link at the end of the currently logged in user string. I'm going to imagin that other administrators will be reporting this as a bug when they upgrade to 2.0. Eventually it'll become the way of life once pervious versions of servers or phased out. What about an administrative option to relaunch browser upon user switching? As it was stated, true security would force logoff and reload browser. So if the Admin could enforce browser reload or not and obviously the browser reload would be off by default... Just a thought...
          Hide
          Steve Bond added a comment -

          I'm probably being dumb but why is this necessary for security?

          This new feature is already really annoying me!

          Show
          Steve Bond added a comment - I'm probably being dumb but why is this necessary for security? This new feature is already really annoying me!
          Hide
          Dragic Janjic added a comment -

          Am I understanding this issue correctly that the logout should happen and is expected due to security? If so, here is a question. When I login as a student for example, and click back on my name I am not logged out, just redirected back to the home page. A coworker of mine, gets logged out.

          Show
          Dragic Janjic added a comment - Am I understanding this issue correctly that the logout should happen and is expected due to security? If so, here is a question. When I login as a student for example, and click back on my name I am not logged out, just redirected back to the home page. A coworker of mine, gets logged out.
          Hide
          Mark Pearson added a comment -

          I second Steve Bond's comment. Why is this essential for security on 2.0 when it was not on 1.9? I hope that we're not going to use 'security' as a catch all reason for any arbitrary policy decision. As the Moodle admin I frequently need to 'login as' a user to check how things look to that user and then I do need to return to the same place.
          I guess I'm intrigued about what possible security breach could occur – cookie malfeasance?

          Show
          Mark Pearson added a comment - I second Steve Bond's comment. Why is this essential for security on 2.0 when it was not on 1.9? I hope that we're not going to use 'security' as a catch all reason for any arbitrary policy decision. As the Moodle admin I frequently need to 'login as' a user to check how things look to that user and then I do need to return to the same place. I guess I'm intrigued about what possible security breach could occur – cookie malfeasance?
          Hide
          Leandro Vilante added a comment -

          I agree with everyone that said it's an annoying functionality. When im configuring the moodle i need to test all the user roles and permissions, witch means a lot of 'login as' and 'login back'. And now it also means a lot of typing of password and loss of time. I'd like to point that i can't see how this will improve security. As administrator i would never leave my computer while logged in moodle or any other system, not even the OS, depending on the case. Also, no one will never blame the system if an administrator does it!

          Show
          Leandro Vilante added a comment - I agree with everyone that said it's an annoying functionality. When im configuring the moodle i need to test all the user roles and permissions, witch means a lot of 'login as' and 'login back'. And now it also means a lot of typing of password and loss of time. I'd like to point that i can't see how this will improve security. As administrator i would never leave my computer while logged in moodle or any other system, not even the OS, depending on the case. Also, no one will never blame the system if an administrator does it!
          Hide
          Richard Redmond added a comment -

          This feature in 2.0 really slows down my technical support for my site. Many times I need to log in as a user in order to troubleshoot a problem. Other times, a student will ask me to upload work that they cannot upload and I need to login as that student. It seems to me that some of the beauty of Moodle is being lost in the upgrade to 2.0. The administrator is losing many of his/her management tools and it seems like the designers feel that the administrators cannot be trusted. ("Login As"/"Viewing Activity Reports from Profile"/"Allowing Course Files"

          Show
          Richard Redmond added a comment - This feature in 2.0 really slows down my technical support for my site. Many times I need to log in as a user in order to troubleshoot a problem. Other times, a student will ask me to upload work that they cannot upload and I need to login as that student. It seems to me that some of the beauty of Moodle is being lost in the upgrade to 2.0. The administrator is losing many of his/her management tools and it seems like the designers feel that the administrators cannot be trusted. ("Login As"/"Viewing Activity Reports from Profile"/"Allowing Course Files"
          Hide
          John Lynch added a comment -

          At the risk of repeating what people have been asking on this thread for months, can someone please clarify what the "security issue" here is? For example, is there actual data that show that, when admin users "log in as" another user, they are more likely to forget that they are also logged in as an admin and therefore create a security risk? This is quite annoying to our entire team, and if Moodle doesn't want to remove this "feature" all together, we'd at least like the ability to easily turn it off.

          Show
          John Lynch added a comment - At the risk of repeating what people have been asking on this thread for months, can someone please clarify what the "security issue" here is? For example, is there actual data that show that, when admin users "log in as" another user, they are more likely to forget that they are also logged in as an admin and therefore create a security risk? This is quite annoying to our entire team, and if Moodle doesn't want to remove this "feature" all together, we'd at least like the ability to easily turn it off.
          Hide
          Michael Green added a comment -

          I'd also like to know why it's necessary for security. Admins should be trusted to use this responsibility. It's a real drag to have to keep logging back in.

          Show
          Michael Green added a comment - I'd also like to know why it's necessary for security. Admins should be trusted to use this responsibility. It's a real drag to have to keep logging back in.
          Hide
          Petr Škoda added a comment -

          The problem is the user that you "login-as" - usually student, they could attack the admin account easily - the attack JS would simply switch back to real user and do whatever it wants. I would personally recommend to close the browser and open it again after switching to any other user.

          Show
          Petr Škoda added a comment - The problem is the user that you "login-as" - usually student, they could attack the admin account easily - the attack JS would simply switch back to real user and do whatever it wants. I would personally recommend to close the browser and open it again after switching to any other user.
          Hide
          Eric Strom added a comment -

          Petr,

          Does this vulnerability exist across the entire moodle installation or is the risk limited to the machine/browser the admin user used to perform the 'login as' function?

          Show
          Eric Strom added a comment - Petr, Does this vulnerability exist across the entire moodle installation or is the risk limited to the machine/browser the admin user used to perform the 'login as' function?
          Hide
          Petr Škoda added a comment -

          Limited? Any registered user could attack anybody else with capability to login as that user. Once you can trick somebody else's browser to execute your javascript code it is game over - attackers can do pretty much anything user can do with mouse or keyboard in that browser frame (for example create new users, change permissions, change passwords, delete courses, etc.)

          Show
          Petr Škoda added a comment - Limited? Any registered user could attack anybody else with capability to login as that user. Once you can trick somebody else's browser to execute your javascript code it is game over - attackers can do pretty much anything user can do with mouse or keyboard in that browser frame (for example create new users, change permissions, change passwords, delete courses, etc.)
          Hide
          Robert Puffer added a comment -

          For those of us watching this issue (lots) I believe what Eric is asking (and I'd echo the question) is, "Is the security weakness limited to the scenario of the exploiting user needing to run the exploit from the same individual machine from which the "login as" took place?

          Show
          Robert Puffer added a comment - For those of us watching this issue (lots) I believe what Eric is asking (and I'd echo the question) is, "Is the security weakness limited to the scenario of the exploiting user needing to run the exploit from the same individual machine from which the "login as" took place?
          Hide
          Petr Škoda added a comment -

          If anybody is interested in more details:
          1/ first study http://en.wikipedia.org/wiki/Cross-site_scripting
          2/ the XSS would happens through My page when user embeds persistent XSS payload that would switch back to original account
          3/ exploit would require a bit of social engineering that tricks the admin to visit user's own My page when logged-as
          4/ XSS is limited only by the permissions of user that is being successfully attacked

          Show
          Petr Škoda added a comment - If anybody is interested in more details: 1/ first study http://en.wikipedia.org/wiki/Cross-site_scripting 2/ the XSS would happens through My page when user embeds persistent XSS payload that would switch back to original account 3/ exploit would require a bit of social engineering that tricks the admin to visit user's own My page when logged-as 4/ XSS is limited only by the permissions of user that is being successfully attacked
          Hide
          Robert Puffer added a comment -

          Is there something wrong with the way we're asking this question? Are you able to answer it?

          Show
          Robert Puffer added a comment - Is there something wrong with the way we're asking this question? Are you able to answer it?
          Hide
          Rex Lorenzo added a comment - - edited

          Wouldn't the cross-site scripting attacks succeed if a user is logged in as a site admin anyways? How does logging in as someone else and viewing any page be different than viewing that same page as a site admin?

          It seems that cross-site scripting is an issue anywhere and preventing someone from returning to their admin role after logging in as someone doesn't solve that problem.

          Show
          Rex Lorenzo added a comment - - edited Wouldn't the cross-site scripting attacks succeed if a user is logged in as a site admin anyways? How does logging in as someone else and viewing any page be different than viewing that same page as a site admin? It seems that cross-site scripting is an issue anywhere and preventing someone from returning to their admin role after logging in as someone doesn't solve that problem.
          Hide
          Petr Škoda added a comment -

          Rex: originally in 1.9.x regular students could not add javascript to html block in their personal "MyPage". In early 2.0dev it was decided to allow JS there in MyPage html blocks for everybody (to allow embedding of external widgets, etc.). Normally you can not view somebody else's MyPage that is why it is usually not a security concern because you may XSS only yourself. Once you LoginAs you may visit MyPage of that other user and that is where it gets tricky, I am personally not sure if the logout mitigates all risks, you should probably close/reopen your browser. I was not involved in the My Page and user profile redesign later in 2.0dev, I did not review or study the code and I did not use this part of Moodle much - so please do not ask me how it works or should work or how to fix bugs there. I only maintain the LoginAs internals in lib/accesslib.php, the logout action is not part of that from my perspective. Since last summer I am not responsible for Moodle security and I am not doing code reviews of the whole code base any more, sorry.

          Show
          Petr Škoda added a comment - Rex: originally in 1.9.x regular students could not add javascript to html block in their personal "MyPage". In early 2.0dev it was decided to allow JS there in MyPage html blocks for everybody (to allow embedding of external widgets, etc.). Normally you can not view somebody else's MyPage that is why it is usually not a security concern because you may XSS only yourself. Once you LoginAs you may visit MyPage of that other user and that is where it gets tricky, I am personally not sure if the logout mitigates all risks, you should probably close/reopen your browser. I was not involved in the My Page and user profile redesign later in 2.0dev, I did not review or study the code and I did not use this part of Moodle much - so please do not ask me how it works or should work or how to fix bugs there. I only maintain the LoginAs internals in lib/accesslib.php, the logout action is not part of that from my perspective. Since last summer I am not responsible for Moodle security and I am not doing code reviews of the whole code base any more, sorry.
          Hide
          Robert Puffer added a comment -

          Petr thanks for the reply. Is it possible to get someone involved in this issue from the core team that actually deals with this issue? How would we proceed?

          Show
          Robert Puffer added a comment - Petr thanks for the reply. Is it possible to get someone involved in this issue from the core team that actually deals with this issue? How would we proceed?
          Hide
          Juho Viitasalo added a comment - - edited

          If the MyPage is really the only thing causing this XSS threat I'd suggest that the javascript on MyPage could be disabled. This would automatically prevent the log out after using the login as functionality. What do you say?

          Show
          Juho Viitasalo added a comment - - edited If the MyPage is really the only thing causing this XSS threat I'd suggest that the javascript on MyPage could be disabled. This would automatically prevent the log out after using the login as functionality. What do you say?
          Hide
          Paul Nicholls added a comment -

          Petr, to expand on Juho's suggestion, could the following be an acceptable solution/workaround?
          If you are using "login as" to view somebody else's "MyPage", custom javascript added by that user is stripped out, and a notice is added to the top of the page along the lines of "For security reasons, any JavaScript added by [user's name] has been removed from this page. Any third-party widgets or other customisations relying on JavaScript will therefore not function as expected." If you think it necessary, the notice could contain a link (which gives a security warning and asks for confirmation before doing anything) which can be clicked to re-display the page with the javascript still in place.

          Alternatively, could we have some kind of mechanism which disables the return to being you which ONLY gets triggered when visiting the other user's "MyPage", perhaps with a warning/confirmation screen being slotted in before the "MyPage" which states that continuing to the user's MyPage will, for security reasons, require you to log in again to return to your account?

          It just seems like overkill to require you to log back in again no matter what you've done if there's only one page in the whole site that's deemed to be a security risk; I'd imagine that the admin would only ever be viewing the user's "MyPage" in a very very small proportion of the cases where they use "login as". It'd be nice to mitigate the actual risk rather than inconvenience people who may never go near the risky page (it may not seem like much of an inconvenience, but as others have suggested, sometimes you can be pinging back and forth between users and it quickly mounts up!).

          Show
          Paul Nicholls added a comment - Petr, to expand on Juho's suggestion, could the following be an acceptable solution/workaround? If you are using "login as" to view somebody else's "MyPage", custom javascript added by that user is stripped out, and a notice is added to the top of the page along the lines of "For security reasons, any JavaScript added by [user's name] has been removed from this page. Any third-party widgets or other customisations relying on JavaScript will therefore not function as expected." If you think it necessary, the notice could contain a link (which gives a security warning and asks for confirmation before doing anything) which can be clicked to re-display the page with the javascript still in place. Alternatively, could we have some kind of mechanism which disables the return to being you which ONLY gets triggered when visiting the other user's "MyPage", perhaps with a warning/confirmation screen being slotted in before the "MyPage" which states that continuing to the user's MyPage will, for security reasons, require you to log in again to return to your account? It just seems like overkill to require you to log back in again no matter what you've done if there's only one page in the whole site that's deemed to be a security risk; I'd imagine that the admin would only ever be viewing the user's "MyPage" in a very very small proportion of the cases where they use "login as". It'd be nice to mitigate the actual risk rather than inconvenience people who may never go near the risky page (it may not seem like much of an inconvenience, but as others have suggested, sometimes you can be pinging back and forth between users and it quickly mounts up!).
          Hide
          Michael de Raadt added a comment -

          I'm shifting this to the DEV backlog as it would require a significant change in the way we have implemented "login as".

          Show
          Michael de Raadt added a comment - I'm shifting this to the DEV backlog as it would require a significant change in the way we have implemented "login as".
          Hide
          hanna edelman added a comment -

          Any news?

          Show
          hanna edelman added a comment - Any news?
          Hide
          Martin Dougiamas added a comment -

          I agree this is an overkill security solution for most sites.

          I think it's probably fair to probably add a setting (off by default) something like:

          "loginas_returntome": Admins logging in as a user will be returned to their original user account. Note that this may expose you to some possible attacks via JS hacks so there is a little risk here if you don't trust all your users.

          Show
          Martin Dougiamas added a comment - I agree this is an overkill security solution for most sites. I think it's probably fair to probably add a setting (off by default) something like: "loginas_returntome": Admins logging in as a user will be returned to their original user account. Note that this may expose you to some possible attacks via JS hacks so there is a little risk here if you don't trust all your users.
          Hide
          Peter Bulmer added a comment -

          Hi Martin,
          Thanks for waking this issue up - looks promising

          If the problem is that we are letting users put unfiltered content on their "my" page, could we give site admins the option to choose between:
          a) Users can put what they like on their 'my' page, but you loginas logs out afterwards
          b) Loginas works like it used to, but user content gets escaped as it goes out.

          Another thought is to restrict loginas from quite doing the right thing for 'my' pages - show escaped content for loginas'd users. In the event that a user's 'my' page needed debugging, you would need a full login as option, but that could suffer the same restriction as we currently have.

          A lot of the time when admins are using loginas functionality, they don't need to view the 'my' page at all, or seeing escaped content would be ok, if we can make this scenario pain-free as possible, then I think that this would be a big win.

          I worry that giving admins an easy-to-use switch that says: "Make everything seem to work, but silently insecure", is very tempting to turn on. When nothing immediately explodes the admin will leave it on and forget about it. They'll either deliberately leave it on, or intend to turn it off after this little task
          Eventually many will suffer at the hands of their users, and not know why. Sure, it's their fault, but their perception of Moodle will suffer as a result.

          Thoughts?

          Show
          Peter Bulmer added a comment - Hi Martin, Thanks for waking this issue up - looks promising If the problem is that we are letting users put unfiltered content on their "my" page, could we give site admins the option to choose between: a) Users can put what they like on their 'my' page, but you loginas logs out afterwards b) Loginas works like it used to, but user content gets escaped as it goes out. Another thought is to restrict loginas from quite doing the right thing for 'my' pages - show escaped content for loginas'd users. In the event that a user's 'my' page needed debugging, you would need a full login as option, but that could suffer the same restriction as we currently have. A lot of the time when admins are using loginas functionality, they don't need to view the 'my' page at all, or seeing escaped content would be ok, if we can make this scenario pain-free as possible, then I think that this would be a big win. I worry that giving admins an easy-to-use switch that says: "Make everything seem to work, but silently insecure", is very tempting to turn on. When nothing immediately explodes the admin will leave it on and forget about it. They'll either deliberately leave it on, or intend to turn it off after this little task Eventually many will suffer at the hands of their users, and not know why. Sure, it's their fault, but their perception of Moodle will suffer as a result. Thoughts?
          Hide
          Petr Škoda added a comment -

          here is the code to "unlogin-as" for course/loginas.php instead of the require_logout() :

          
              $_SESSION['SESSION'] = $_SESSION['REALSESSION'];
              $_SESSION['USER'] = $_SESSION['REALUSER'];
          
              unset($_SESSION['REALSESSION']);
              unset($_SESSION['REALUSER']);
          
              if ($id and $id != SITEID) {
                  redirect("$CFG->wwwroot/course/view.php?id=".$id);
              } else {
                  redirect("$CFG->wwwroot/");
              }
          

          I do not want to put my name next to this code that intentionally opens XSS in Moodle. Maybe there are other places with similar problems as the my moodle page or profiles, somebody needs to carefully review all blocks and user profiles code.

          Show
          Petr Škoda added a comment - here is the code to "unlogin-as" for course/loginas.php instead of the require_logout() : $_SESSION['SESSION'] = $_SESSION['REALSESSION']; $_SESSION['USER'] = $_SESSION['REALUSER']; unset($_SESSION['REALSESSION']); unset($_SESSION['REALUSER']); if ($id and $id != SITEID) { redirect( "$CFG->wwwroot/course/view.php?id=" .$id); } else { redirect( "$CFG->wwwroot/" ); } I do not want to put my name next to this code that intentionally opens XSS in Moodle. Maybe there are other places with similar problems as the my moodle page or profiles, somebody needs to carefully review all blocks and user profiles code.
          Hide
          Fernando Oliveira added a comment - - edited

          Thanks Petr. Just to be clear, the code you provide will prevent admin user logout when using the "login as" function? If so, where can I insert this code?

          ...nevermind. Found the "require_logout()" line. Seems to do the trick. Thanks for for this.

          Show
          Fernando Oliveira added a comment - - edited Thanks Petr. Just to be clear, the code you provide will prevent admin user logout when using the "login as" function? If so, where can I insert this code? ...nevermind. Found the "require_logout()" line. Seems to do the trick. Thanks for for this.

            Dates

            • Created:
              Updated: