[Critique] Un username égal à l'email d'un autre utilisateur bloque son login par email (500) #92

New issue

Closed

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

asventi commented

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

Owner

Gravité : Critique
Rapports QA d'origine : AUTH-01, PROFILE-03

Le login cherche UserName == login || Email == email avec SingleOrDefault : deux résultats provoquent « Sequence contains more than one element ». Possible à l'inscription comme en renommant son compte.

Détails des rapports

[AUTH-01] Un user peut verrouiller le login par email de n'importe quel autre user (username = email de la victime -> 500) — Gravité : Critique

Où : POST /api/auth/login + POST /api/auth/register
Étapes : 1. Victime qa_auth_log_hys19 (email qa_auth_log_hys19@qa.test). 2. Avec une invitation valide, s'inscrire avec userName = qa_auth_log_hys19@qa.test (accepté : 201, aucune règle sur le format du username) et un autre email. 3. Victime : POST /auth/login {"login":"qa_auth_log_hys19@qa.test", ...}.
Attendu : login OK (ou username qui ne peut pas ressembler à un email).
Obtenu : 500 System.InvalidOperationException: Sequence contains more than one element. pour la victime (par email) ET pour l'attaquant (par son username). Login par username de la victime reste OK. Un attaquant peut donc empêcher n'importe quel user (y compris un admin, dont l'email est visible) de se connecter par email.
Preuve : réponses API ci-dessus (script scripts/auth/d_edge.py, e_dup.py).
Cause probable : backend/API/Auth/Login/LoginUserCommand.cs:16 (SingleOrDefaultAsync(u => u.UserName == req.Login || u.Email == email)) + absence de contrainte sur le username (RegisterEndpoint.cs:9).

[PROFILE-03] Renommer son compte avec l'email d'un autre user bloque la connexion par email de la victime (HTTP 500) — Gravité : Majeur

Où : PATCH /api/me puis POST /api/auth/login
Étapes : 1. User B (qa) a l'email qa_profile_eh92v@qa.test. 2. User A renomme son userName en exactement cet email : PATCH /api/me {"userName":"qa_profile_eh92v@qa.test"} -> 200. 3. POST /api/auth/login {"login":"qa_profile_eh92v@qa.test","password":<mdp de B>}.
Attendu : refus du rename (collision username/email) ; login de B OK.
Obtenu : 500 System.InvalidOperationException: Sequence contains more than one element (même avec le bon mot de passe de B ; B ne peut plus se connecter que par son username). N'importe quel user peut ainsi empêcher n'importe quel autre de se connecter par email, sans connaître son mot de passe. Le 500 expose aussi le détail de l'exception (champ exception) dans la réponse.
Cause probable : backend/API/Auth/Login/LoginUserCommand.cs:16 SingleOrDefaultAsync(u => u.UserName == req.Login || u.Email == email) + aucune vérification que UserName ne ressemble pas à un email d'autrui dans UpdateMeCommand.cs/RegisterUserCommand.cs.

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-01, PROFILE-03 Le login cherche `UserName == login || Email == email` avec `SingleOrDefault` : deux résultats provoquent « Sequence contains more than one element ». Possible à l'inscription comme en renommant son compte. ## Détails des rapports <details><summary>[AUTH-01] Un user peut verrouiller le login par email de n'importe quel autre user (username = email de la victime -> 500) — Gravité : Critique</summary> - Où : `POST /api/auth/login` + `POST /api/auth/register` - Étapes : 1. Victime `qa_auth_log_hys19` (email `qa_auth_log_hys19@qa.test`). 2. Avec une invitation valide, s'inscrire avec `userName` = `qa_auth_log_hys19@qa.test` (accepté : 201, aucune règle sur le format du username) et un autre email. 3. Victime : `POST /auth/login {"login":"qa_auth_log_hys19@qa.test", ...}`. - Attendu : login OK (ou username qui ne peut pas ressembler à un email). - Obtenu : `500 System.InvalidOperationException: Sequence contains more than one element.` pour la victime (par email) ET pour l'attaquant (par son username). Login par username de la victime reste OK. Un attaquant peut donc empêcher n'importe quel user (y compris un admin, dont l'email est visible) de se connecter par email. - Preuve : réponses API ci-dessus (script `scripts/auth/d_edge.py`, `e_dup.py`). - Cause probable : `backend/API/Auth/Login/LoginUserCommand.cs:16` (`SingleOrDefaultAsync(u => u.UserName == req.Login || u.Email == email)`) + absence de contrainte sur le username (`RegisterEndpoint.cs:9`). </details> <details><summary>[PROFILE-03] Renommer son compte avec l'email d'un autre user bloque la connexion par email de la victime (HTTP 500) — Gravité : Majeur</summary> - Où : `PATCH /api/me` puis `POST /api/auth/login` - Étapes : 1. User B (qa) a l'email `qa_profile_eh92v@qa.test`. 2. User A renomme son userName en exactement cet email : `PATCH /api/me {"userName":"qa_profile_eh92v@qa.test"}` -> 200. 3. `POST /api/auth/login {"login":"qa_profile_eh92v@qa.test","password":<mdp de B>}`. - Attendu : refus du rename (collision username/email) ; login de B OK. - Obtenu : 500 `System.InvalidOperationException: Sequence contains more than one element` (même avec le bon mot de passe de B ; B ne peut plus se connecter que par son username). N'importe quel user peut ainsi empêcher n'importe quel autre de se connecter par email, sans connaître son mot de passe. Le 500 expose aussi le détail de l'exception (champ `exception`) dans la réponse. - Cause probable : `backend/API/Auth/Login/LoginUserCommand.cs:16` `SingleOrDefaultAsync(u => u.UserName == req.Login || u.Email == email)` + aucune vérification que `UserName` ne ressemble pas à un email d'autrui dans `UpdateMeCommand.cs`/`RegisterUserCommand.cs`. </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:15 +00:00