[Critique] Escalade de privilèges : HandleUsers permet de réinitialiser le mot de passe ou de supprimer un utilisateur plus privilégié #88

New issue

Closed

opened 2026-10-28 10:31:51 +00:00 by asventi · 0 comments

asventi commented

2026-10-28 10:31:51 +00:00

Owner

Gravité : Critique
Rapports QA d'origine : AUTH-10, ADMIN-07

Un rôle avec seulement HandleUsers peut reset le mot de passe d'un admin, se connecter avec et prendre son compte. Seul dede est protégé.

Détails des rapports

[AUTH-10] Un rôle `HandleUsers` peut réinitialiser le mot de passe d'un user plus privilégié et prendre son compte (escalade de privilèges) — Gravité : Critique

Où : PATCH /api/auth/{id}/password (UI : bouton reset password de /admin/users)
Étapes : 1. qa_auth_adm_* a le rôle qa HandleUsers|InviteUser (permission 6). 2. qa_auth_sup_* a un rôle qa avec toutes les permissions (127). 3. L'admin 6 appelle PATCH /auth/<id sup>/password avec "Takeover-1234" -> 200. 4. Login en tant que qa_auth_sup_* avec ce mot de passe -> 200, /me : permission: 127.
Attendu : refus quand la cible a des permissions que l'appelant n'a pas (ou au moins pour les rôles supérieurs).
Obtenu : prise de contrôle complète. Seule protection : le compte DefaultAdminLogin (ResetPasswordQuery.cs:22). Les users tom/Gold (toutes permissions) sont concernés de la même façon (non testé sur eux, comptes réservés).
Cause probable : backend/API/Auth/Reset/ResetPasswordQuery.cs:13-31 (aucun contrôle de hiérarchie).

[ADMIN-07] Escalade de privilèges : HandleUsers seul permet de réinitialiser le mot de passe de n'importe quel user (même plus privilégié) et de le supprimer — Gravité : Critique

Où : PATCH /api/auth/{id}/password, DELETE /api/users/{id}
Étapes : 1. User qa avec uniquement HandleUsers 2. PATCH /api/auth/<id d'un user qa ayant toutes les perms>/password avec "Hacked-pass-123" 3. Login avec ce nouveau mot de passe
Obtenu : 200 ; le login du user privilégié avec le nouveau mot de passe fonctionne -> prise de contrôle d'un compte admin. Le même user peut aussi DELETE /api/users/<id privilégié> -> 200.
Seul le compte dede est protégé (UserCannotBeDelete / PasswordCannotBeChanged), pas les autres admins (Gold/tom).
Preuve : script scripts/admin/t4_priv.py : HandleUsers-only: reset pwd of privileged qa user -> 200 ; login ... OK -> ESCALATION PATH.
Cause probable : backend/API/Auth/Reset/ResetPasswordQuery.cs, backend/API/Users/Delete/DeleteUserQuery.cs : pas de comparaison de niveau de privilège entre acteur et cible.

Trouvé par une campagne de tests QA automatisés (agents Claude, Playwright) sur l'environnement de dev. Les captures citées sont locales et non jointes.

**Gravité :** Critique **Rapports QA d'origine :** AUTH-10, ADMIN-07 Un rôle avec seulement HandleUsers peut reset le mot de passe d'un admin, se connecter avec et prendre son compte. Seul dede est protégé. ## Détails des rapports <details><summary>[AUTH-10] Un rôle `HandleUsers` peut réinitialiser le mot de passe d'un user plus privilégié et prendre son compte (escalade de privilèges) — Gravité : Critique</summary> - Où : `PATCH /api/auth/{id}/password` (UI : bouton reset password de /admin/users) - Étapes : 1. `qa_auth_adm_*` a le rôle qa `HandleUsers|InviteUser` (permission 6). 2. `qa_auth_sup_*` a un rôle qa avec toutes les permissions (127). 3. L'admin 6 appelle `PATCH /auth/<id sup>/password` avec `"Takeover-1234"` -> 200. 4. Login en tant que `qa_auth_sup_*` avec ce mot de passe -> 200, `/me` : `permission: 127`. - Attendu : refus quand la cible a des permissions que l'appelant n'a pas (ou au moins pour les rôles supérieurs). - Obtenu : prise de contrôle complète. Seule protection : le compte `DefaultAdminLogin` (`ResetPasswordQuery.cs:22`). Les users tom/Gold (toutes permissions) sont concernés de la même façon (non testé sur eux, comptes réservés). - Cause probable : `backend/API/Auth/Reset/ResetPasswordQuery.cs:13-31` (aucun contrôle de hiérarchie). </details> <details><summary>[ADMIN-07] Escalade de privilèges : HandleUsers seul permet de réinitialiser le mot de passe de n'importe quel user (même plus privilégié) et de le supprimer — Gravité : Critique</summary> - Où : `PATCH /api/auth/{id}/password`, `DELETE /api/users/{id}` - Étapes : 1. User qa avec uniquement HandleUsers 2. `PATCH /api/auth/<id d'un user qa ayant toutes les perms>/password` avec "Hacked-pass-123" 3. Login avec ce nouveau mot de passe - Obtenu : 200 ; le login du user privilégié avec le nouveau mot de passe fonctionne -> prise de contrôle d'un compte admin. Le même user peut aussi `DELETE /api/users/<id privilégié>` -> 200. Seul le compte `dede` est protégé (`UserCannotBeDelete` / `PasswordCannotBeChanged`), pas les autres admins (Gold/tom). - Preuve : script `scripts/admin/t4_priv.py` : `HandleUsers-only: reset pwd of privileged qa user -> 200` ; `login ... OK -> ESCALATION PATH`. - Cause probable : `backend/API/Auth/Reset/ResetPasswordQuery.cs`, `backend/API/Users/Delete/DeleteUserQuery.cs` : pas de comparaison de niveau de privilège entre acteur et cible. </details> --- _Trouvé par une campagne de tests QA automatisés (agents Claude, Playwright) sur l'environnement de dev. Les captures citées sont locales et non jointes._

asventi added the

bug

label

2026-10-28 10:44:13 +00:00