[Critique] La permission HandleKnowledge n'est jamais vérifiée : tout utilisateur peut uploader, renommer et supprimer les fichiers des autres #86

New issue

Closed

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

asventi commented

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

Owner

Gravité : Critique
Rapports QA d'origine : FILES-01, ADMIN-05, SECURITY_UX-07

Aucun [Roles(Perms.HandleKnowledge)] sur les endpoints /files : un Member (permission 0) modifie et supprime les fichiers de l'admin.

Détails des rapports

[FILES-01] La permission HandleKnowledge n'est jamais appliquée : un Member (permission 0) peut uploader, renommer et supprimer n'importe quel fichier — Gravité : Critique

Où : POST /api/files, PATCH /api/files/{key}/name, DELETE /api/files/{key}
Étapes : 1. Créer un user qa (rôle Member, permission: 0). 2. Avec son cookie : POST /api/files (multipart name+file) ; PATCH le fichier d'un autre (créé par dede) ; DELETE le fichier d'un autre.
Attendu : 403 pour un user sans HandleKnowledge (au moins pour renommer/supprimer ; idéalement upload aussi).
Obtenu : upload 201, rename 200 (le nom du fichier de dede est changé), delete 204 (fichier de dede réellement supprimé, meta -> 404 ensuite).
Preuve : script scripts/files_ai/qa_files_12_shots.py (le script d'origine a été perdu ; les appels API sont triviaux à rejouer avec Api(member)) (sortie : 4 member rename admin file: 200, 4 member delete admin file: 204 -> admin meta 404) ; en UI (qa_files_08_member_ui.py, screenshots screens/qa_files_12_member_knowledge_actions.png, qa_files_12_member_menu_on_admin_file.png) : le Member voit « Upload », « New folder » et le menu d'actions (rename/move/delete) sur TOUS les fichiers, et a réussi à renommer puis supprimer un fichier appartenant à dede ; l'API confirme ensuite 404 sur ce fichier.
Cause probable : backend/API/Storage/*/…Endpoint.cs : seulement [Authorize], aucune vérification de Perms.HandleKnowledge ; grep HandleKnowledge backend/API ne trouve que sa déclaration dans Roles/Roles.cs:23. Côté front, aucune vérification non plus (frontend/src/files/components/FileList.tsx, ItemActions.tsx affichent les actions à tous).

[ADMIN-05] La permission HandleKnowledge n'est appliquée nulle part : tout utilisateur peut renommer / supprimer les fichiers des autres — Gravité : Critique

Où : PATCH /api/files/{key}/name, DELETE /api/files/{key} (page /knowledge)
Étapes : 1. User A (Member) uploade un fichier 2. User B (rôle qa avec 0 permission, ou n'importe quel autre rôle) : PATCH /api/files/<key>/name puis DELETE /api/files/<key>
Attendu : seuls HandleKnowledge (ou le créateur) peuvent modifier/supprimer.
Obtenu : 200 (rename) et 204 (delete) pour TOUS les 9 acteurs testés (Member, et chacun des 7 rôles à permission unique, plus Users+Roles), y compris ceux qui n'ont pas HandleKnowledge.
A l'inverse le rôle qui n'a QUE HandleKnowledge n'a aucun avantage.
Preuve : sortie de la matrice : lignes PATCH other's file name / DELETE other's file = 200/204 dans toutes les colonnes.
Cause probable : backend/API/Storage/Delete/DeleteFileEndpoint.cs:11, Storage/Update/UpdateFileNameEndpoint.cs:18, Storage/Upload/UploadFileEndpoint.cs:40 : [Authorize] seul ; Perms.HandleKnowledge jamais référencé (grep). Côté front aucun test de PermEnum.HandleKnowledge non plus (routes/knowledge.tsx).

[SECURITY_UX-07] N'importe quel utilisateur peut renommer ou supprimer les fichiers des autres — Gravité : Critique

Où : PATCH /api/files/{key}/name, DELETE /api/files/{key}
Étapes : 1. A (Member) uploade un fichier (POST /files, 201). 2. C (autre Member, sans aucune permission) PATCH /files/{key}/name {"name":"qa_sec_renamed_by_C.txt"} -> 200, puis DELETE /files/{key} -> 204. 3. A relit GET /files/meta/{key} -> 404 (fichier perdu, supprimé aussi du stockage S3).
Attendu : 403 si non propriétaire / sans permission HandleKnowledge (jamais vérifiée côté backend). Cela concerne aussi les fichiers d'événements, les avatars et les documents de la base de connaissance.
Cause probable : backend/API/Storage/Delete/DeleteFileEndpoint.cs:11, Storage/Update/UpdateFileNameEndpoint.cs:18 (seulement [Authorize]), DeleteFileCommand/UpdateFileNameCommand ne comparent pas Creator au user courant. De même POST /files n'exige aucune permission.

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 :** FILES-01, ADMIN-05, SECURITY_UX-07 Aucun `[Roles(Perms.HandleKnowledge)]` sur les endpoints `/files` : un Member (permission 0) modifie et supprime les fichiers de l'admin. ## Détails des rapports <details><summary>[FILES-01] La permission HandleKnowledge n'est jamais appliquée : un Member (permission 0) peut uploader, renommer et supprimer n'importe quel fichier — Gravité : Critique</summary> - Où : `POST /api/files`, `PATCH /api/files/{key}/name`, `DELETE /api/files/{key}` - Étapes : 1. Créer un user qa (rôle Member, `permission: 0`). 2. Avec son cookie : POST /api/files (multipart name+file) ; PATCH le fichier d'un autre (créé par dede) ; DELETE le fichier d'un autre. - Attendu : 403 pour un user sans `HandleKnowledge` (au moins pour renommer/supprimer ; idéalement upload aussi). - Obtenu : upload 201, rename 200 (le nom du fichier de dede est changé), delete 204 (fichier de dede réellement supprimé, meta -> 404 ensuite). - Preuve : script `scripts/files_ai/qa_files_12_shots.py` (le script d'origine a été perdu ; les appels API sont triviaux à rejouer avec `Api(member)`) (sortie : `4 member rename admin file: 200`, `4 member delete admin file: 204 -> admin meta 404`) ; en UI (`qa_files_08_member_ui.py`, screenshots `screens/qa_files_12_member_knowledge_actions.png`, `qa_files_12_member_menu_on_admin_file.png`) : le Member voit « Upload », « New folder » et le menu d'actions (rename/move/delete) sur TOUS les fichiers, et a réussi à renommer puis supprimer un fichier appartenant à dede ; l'API confirme ensuite 404 sur ce fichier. - Cause probable : `backend/API/Storage/*/…Endpoint.cs` : seulement `[Authorize]`, aucune vérification de `Perms.HandleKnowledge` ; `grep HandleKnowledge backend/API` ne trouve que sa déclaration dans `Roles/Roles.cs:23`. Côté front, aucune vérification non plus (`frontend/src/files/components/FileList.tsx`, `ItemActions.tsx` affichent les actions à tous). </details> <details><summary>[ADMIN-05] La permission HandleKnowledge n'est appliquée nulle part : tout utilisateur peut renommer / supprimer les fichiers des autres — Gravité : Critique</summary> - Où : `PATCH /api/files/{key}/name`, `DELETE /api/files/{key}` (page /knowledge) - Étapes : 1. User A (Member) uploade un fichier 2. User B (rôle qa avec 0 permission, ou n'importe quel autre rôle) : `PATCH /api/files/<key>/name` puis `DELETE /api/files/<key>` - Attendu : seuls HandleKnowledge (ou le créateur) peuvent modifier/supprimer. - Obtenu : 200 (rename) et 204 (delete) pour TOUS les 9 acteurs testés (Member, et chacun des 7 rôles à permission unique, plus Users+Roles), y compris ceux qui n'ont pas HandleKnowledge. A l'inverse le rôle qui n'a QUE HandleKnowledge n'a aucun avantage. - Preuve : sortie de la matrice : lignes `PATCH other's file name` / `DELETE other's file` = 200/204 dans toutes les colonnes. - Cause probable : `backend/API/Storage/Delete/DeleteFileEndpoint.cs:11`, `Storage/Update/UpdateFileNameEndpoint.cs:18`, `Storage/Upload/UploadFileEndpoint.cs:40` : `[Authorize]` seul ; `Perms.HandleKnowledge` jamais référencé (grep). Côté front aucun test de `PermEnum.HandleKnowledge` non plus (`routes/knowledge.tsx`). </details> <details><summary>[SECURITY_UX-07] N'importe quel utilisateur peut renommer ou supprimer les fichiers des autres — Gravité : Critique</summary> - Où : `PATCH /api/files/{key}/name`, `DELETE /api/files/{key}` - Étapes : 1. A (Member) uploade un fichier (`POST /files`, 201). 2. C (autre Member, sans aucune permission) `PATCH /files/{key}/name {"name":"qa_sec_renamed_by_C.txt"}` -> 200, puis `DELETE /files/{key}` -> 204. 3. A relit `GET /files/meta/{key}` -> 404 (fichier perdu, supprimé aussi du stockage S3). - Attendu : 403 si non propriétaire / sans permission `HandleKnowledge` (jamais vérifiée côté backend). Cela concerne aussi les fichiers d'événements, les avatars et les documents de la base de connaissance. - Cause probable : `backend/API/Storage/Delete/DeleteFileEndpoint.cs:11`, `Storage/Update/UpdateFileNameEndpoint.cs:18` (seulement `[Authorize]`), `DeleteFileCommand`/`UpdateFileNameCommand` ne comparent pas `Creator` au user courant. De même `POST /files` n'exige aucune permission. </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