[Majeur] Unicité du username sensible à la casse et aux espaces (usurpation de « dede ») #104

New issue

Closed

opened 2026-10-28 10:32:01 +00:00 by asventi · 0 comments

asventi commented

2026-10-28 10:32:01 +00:00

Owner

Gravité : Majeur
Rapports QA d'origine : AUTH-04, PROFILE-02

« DEDE » ou « dede » sont acceptés ; retours à la ligne, caractères invisibles et 255 caractères aussi.

Détails des rapports

[AUTH-04] Unicité du username sensible à la casse et aux espaces (usurpation d'identité visuelle) — Gravité : Mineur

Où : POST /api/auth/register
Étapes : 1. Inscrire qa_auth_dupo1fp. 2. Inscrire QA_AUTH_DUPO1FP -> 201. 3. Inscrire qa_auth_dupo1fp (espace final) -> 201 (l'UI trim, pas l'API). L'email, lui, est normalisé (409 pour ...@QA.TEST et avec espaces).
Attendu : 409 (comparaison insensible à la casse, username trimé).
Obtenu : 3 comptes au nom quasi identique ; sur la base de données réelle on pourrait créer Dede / dede en lookalike de l'admin. Le login par username est lui sensible à la casse (DEDE != dede -> 406) alors que le login par email ne l'est pas.
Cause probable : RegisterUserCommand.cs:28 (e.UserName == req.UserName), LoginUserCommand.cs:16.

[PROFILE-02] Unicité du nom d'utilisateur sensible à la casse / espaces : usurpation possible de "dede" — Gravité : Majeur

Où : PATCH /api/me (et POST /api/auth/register, même logique)
Étapes : 1. Connecté en tant que user qa : PATCH /api/me {"userName":"DEDE"} puis {"userName":"dede "} (espace final).
Attendu : 409 "Username already used" (nom déjà pris par l'admin dede), ou nom normalisé/trimé.
Obtenu : 200 dans les deux cas : le user qa apparaît dans la liste des membres/messages sous "DEDE" ou "dede " (rôle Member), indiscernable de l'admin. Idem pour "tom" -> "Tom", etc. Caractères invisibles (U+200B), retours à la ligne ("a\nb") et noms de 255 caractères aussi acceptés.
Preuve : réponses API 200 {"userName":"DEDE"}, 200 {"userName":"dede "}, 200 {"userName":"a\nb"}, 200 pour 255 'a'.
Cause probable : backend/API/Users/Me/Update/UpdateMeCommand.cs:17 (u.UserName == req.UserName, comparaison exacte) ; pas de Trim/normalisation ; UpdateMeEndpoint.cs:14 [Length(1,255)] ; idem Auth/Register/RegisterUserCommand.cs:25.

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é :** Majeur **Rapports QA d'origine :** AUTH-04, PROFILE-02 « DEDE » ou « dede » sont acceptés ; retours à la ligne, caractères invisibles et 255 caractères aussi. ## Détails des rapports <details><summary>[AUTH-04] Unicité du username sensible à la casse et aux espaces (usurpation d'identité visuelle) — Gravité : Mineur</summary> - Où : `POST /api/auth/register` - Étapes : 1. Inscrire `qa_auth_dupo1fp`. 2. Inscrire `QA_AUTH_DUPO1FP` -> 201. 3. Inscrire `qa_auth_dupo1fp ` (espace final) -> 201 (l'UI trim, pas l'API). L'email, lui, est normalisé (409 pour `...@QA.TEST` et avec espaces). - Attendu : 409 (comparaison insensible à la casse, username trimé). - Obtenu : 3 comptes au nom quasi identique ; sur la base de données réelle on pourrait créer `Dede` / `dede ` en lookalike de l'admin. Le login par username est lui sensible à la casse (`DEDE` != `dede` -> 406) alors que le login par email ne l'est pas. - Cause probable : `RegisterUserCommand.cs:28` (`e.UserName == req.UserName`), `LoginUserCommand.cs:16`. </details> <details><summary>[PROFILE-02] Unicité du nom d'utilisateur sensible à la casse / espaces : usurpation possible de "dede" — Gravité : Majeur</summary> - Où : `PATCH /api/me` (et `POST /api/auth/register`, même logique) - Étapes : 1. Connecté en tant que user qa : `PATCH /api/me {"userName":"DEDE"}` puis `{"userName":"dede "}` (espace final). - Attendu : 409 "Username already used" (nom déjà pris par l'admin `dede`), ou nom normalisé/trimé. - Obtenu : 200 dans les deux cas : le user qa apparaît dans la liste des membres/messages sous "DEDE" ou "dede " (rôle Member), indiscernable de l'admin. Idem pour "tom" -> "Tom", etc. Caractères invisibles (U+200B), retours à la ligne (`"a\nb"`) et noms de 255 caractères aussi acceptés. - Preuve : réponses API `200 {"userName":"DEDE"}`, `200 {"userName":"dede "}`, `200 {"userName":"a\nb"}`, `200` pour 255 'a'. - Cause probable : `backend/API/Users/Me/Update/UpdateMeCommand.cs:17` (`u.UserName == req.UserName`, comparaison exacte) ; pas de `Trim`/normalisation ; `UpdateMeEndpoint.cs:14` `[Length(1,255)]` ; idem `Auth/Register/RegisterUserCommand.cs:25`. </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