Sudo mode - admin session

Context

Prevent:

• user creation (fetch POST user.form.php) by an attacker exploiting a XSS

• physical (desktop session kept open) access to an admin computer should not allow destructive actions on GLPI.

All these actions should be at least protected and the admin should confirm its session.

For example, GitHub (check screen below) and Gitlab ask for a confirmation.

Proposal

Force an authentication confirmation when a destructive or dangerous operation is performed.

We don’t need to make a confirmation for each action, the mechanism can be set in session for a defined time.

Here is the prompt required depending on the logged user state:

• Ask for a TOTP code if MFA enabled

• Send an email and ask for a transmitted code ? And suggest enable MFA ?

• Ask for password check, if local login

• Ask for password check, if ldap login (even with an external auto-login)

• Ask for oauth check. This case may be complex to do as login is handled by a plugin

Please note that we can make 2 options possible, one in priority (TOTP code), and one optional to avoid the admin be blocked without options.

We should make a message explaining the requirement, the duration, etc

Please note:

• API or CLI operations should not be impacted by this mechanism

• This should be enforced by backend, a frontend JavaScript code should not be able to bypass the mechanism.

• We should trigger the prompt on arrival on a page (like user creation form).

  But if the session is not active yet and a POST is sent directly (like in XSS), it should be prevented, then the prompt displayed. In this case, I think it’s preferable to lose post data.

• The delay of the sudo move should be sufficient to avoid admins to be annoyed by it.

• We may allow disabling the process by a backend constant ? This may be useful for development.

  
  

  
  

List of operations:

Maybe we can protect globally Administration and Setup menu, Gitlab does like that, but it’s a bit annoying in my opinion. I still can live with it if it’s simplifies greatly the development of the feature.

But at least, these operations SHOULD be protected:

• User creation

• Password change from administration (preferences page asks for previous one)

• Impersonation

• MFA deactivation (User / Group / Profile / General)

• Profiles attribution

• In Setup > General

  • FAQ public toggle (open endpoint)

  • API (legacy/HL) toggle

  • Proxy setup (MITM)

  • Security

• Security policies changes (User / Group / Profile / General)

• All pages under Administration > Logs

• All pages under Administration > Inventory

• All pages under Setup > Authentication

• All pages under Setup > Oauth client

  
  

Evolutions

Proposals that emerged when producing the feature.

Sliding window time

After processing a reauthentication, user is considered reauthenticated for 15 minutes. That’s a non sliding time window, expiration is determined at the reauthentication time.
Instead we can a sliding/floating time window. This prevent the user for reauth prompt if he was still acting on the glpi. The window may slide on any action (any CRUD operation, including Reading) or may happend only on reauth restricted actions.

Resilient reauthentication strategies

A strategy is a way to process reauth (totp, password, etc).

At the moment the valid strategy with highest priority is used. If it doesn’t work (e.g. broken implementation, runtime error) an error is processed and the user can’t process any reauth needed action.
We can imagine that a broken process can be automatically disabled and the next reauth strategy is proposed to the user.