[Mineur] Fichiers : validation des noms et du contenu (../, //, vide, Content-Type invalide) #122

New issue

Closed

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

asventi commented

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

Owner

Gravité : Mineur
Rapports QA d'origine : FILES-03, FILES-04, FILES-05, FILES-09

Content-Type invalide ou NUL dans le nom donnent 500 avec un objet S3 orphelin ; fichier de 0 octet accepté alors que StorageProblems.EmptyFile existe ; noms ../x ou //x acceptés ; aucune unicité de nom.

Détails des rapports

[FILES-03] 500 (avec détails d'exception) sur Content-Type invalide/vide et sur NUL (\x00) dans le nom — Gravité : Mineur

Où : POST /api/files
Étapes : 1. Uploader avec Content-Type de la partie file = not/a valid; type ou vide. 2. Uploader avec name contenant \x00.
Attendu : 400/422 propre.
Obtenu : 500 System.FormatException: The format of value '...' is invalid (content-type), 500 DbUpdateException (NUL, rejeté par PostgreSQL) ; le corps JSON contient la stack trace (env. Development). Dans le cas content-type, l'objet n'est pas stocké mais l'erreur n'est pas gérée ; dans le cas NUL, l'objet S3 est déjà uploadé (orphelin) avant l'échec de la DB.
Cause probable : backend/API/Storage/Garage.cs:17-25 (ContentType passé tel quel à PutObjectRequest), Upload/UploadFileCommand.cs:12-34 (S3 d'abord, DB ensuite, pas de rollback).

[FILES-04] Fichier vide (0 octet) accepté alors qu'un problème `EmptyFile` existe — Gravité : Mineur

Où : POST /api/files avec 0 octet -> 201 (length 0). StorageProblems.EmptyFile() (422 FILE_EMPTY) existe mais n'est jamais appelé. (Remarque : la création de dossier côté front utilise volontairement un fichier vide File([], name) nommé /dossier/, donc l'interdire casserait les dossiers.)
Cause probable : backend/API/Problems/StorageProblems.cs:12, Upload/UploadFileCommand.cs.

[FILES-05] L'API accepte n'importe quel nom (`../x`, `//x`, sans `/` initial, `/dir/`) : dossiers « .. » et sans nom dans l'UI, fichiers invisibles — Gravité : Mineur

Où : POST /api/files / PATCH /api/files/{key}/name : seule validation = longueur 1..255. Le front attend des noms de la forme /dossier/fichier. Un fichier nommé noslash.txt ou ../x.txt ne commence pas par / donc n'apparaît dans aucun dossier (useFileBrowser.ts filtre startsWith(currFolder)), et getRecentFiles (files.api.ts) ne retient que les noms commençant par /.
Obtenu (UI, vérifié) : à la racine de /knowledge, //qa_files_double.txt crée une ligne de dossier SANS nom, /../../etc/passwd crée un dossier nommé .. (confondable avec le bouton « remonter ») ; noslash.txt / ../qa_files_dotdot.txt n'apparaissent nulle part (invisibles, non supprimables par l'UI). Preuve : screens/qa_files_12_root_weird_and_long.png.
Cause probable : validation serveur limitée à [Length(1,255)] (Storage/Upload/UploadFileEndpoint.cs:14, Update/UpdateFileNameEndpoint.cs:10) ; la convention « /dossier/nom » n'est vérifiée que côté front (FileUpload.tsx).

[FILES-09] Aucune unicité de nom : deux fichiers (ou plus) identiques dans le même dossier — Gravité : Mineur

Uploader deux fois qa_files_dup.txt dans le même dossier (UI) -> deux lignes identiques, indiscernables (même taille, même icône, sans date ni auteur affichés) ; idem après un « Move » vers un dossier contenant déjà le même nom. Aucun avertissement. Un renommage vers un nom existant est aussi accepté. (Comportement probablement voulu côté API, mais l'UI ne permet pas de distinguer les doublons.)

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é :** Mineur **Rapports QA d'origine :** FILES-03, FILES-04, FILES-05, FILES-09 Content-Type invalide ou NUL dans le nom donnent 500 avec un objet S3 orphelin ; fichier de 0 octet accepté alors que `StorageProblems.EmptyFile` existe ; noms `../x` ou `//x` acceptés ; aucune unicité de nom. ## Détails des rapports <details><summary>[FILES-03] 500 (avec détails d'exception) sur Content-Type invalide/vide et sur NUL (\x00) dans le nom — Gravité : Mineur</summary> - Où : `POST /api/files` - Étapes : 1. Uploader avec `Content-Type` de la partie file = `not/a valid; type` ou vide. 2. Uploader avec name contenant `\x00`. - Attendu : 400/422 propre. - Obtenu : 500 `System.FormatException: The format of value '...' is invalid` (content-type), 500 `DbUpdateException` (NUL, rejeté par PostgreSQL) ; le corps JSON contient la stack trace (env. Development). Dans le cas content-type, l'objet n'est pas stocké mais l'erreur n'est pas gérée ; dans le cas NUL, l'objet S3 est déjà uploadé (orphelin) avant l'échec de la DB. - Cause probable : `backend/API/Storage/Garage.cs:17-25` (ContentType passé tel quel à PutObjectRequest), `Upload/UploadFileCommand.cs:12-34` (S3 d'abord, DB ensuite, pas de rollback). </details> <details><summary>[FILES-04] Fichier vide (0 octet) accepté alors qu'un problème `EmptyFile` existe — Gravité : Mineur</summary> - Où : `POST /api/files` avec 0 octet -> 201 (length 0). `StorageProblems.EmptyFile()` (422 FILE_EMPTY) existe mais n'est jamais appelé. (Remarque : la création de dossier côté front utilise volontairement un fichier vide `File([], name)` nommé `/dossier/`, donc l'interdire casserait les dossiers.) - Cause probable : `backend/API/Problems/StorageProblems.cs:12`, `Upload/UploadFileCommand.cs`. </details> <details><summary>[FILES-05] L'API accepte n'importe quel nom (`../x`, `//x`, sans `/` initial, `/dir/`) : dossiers « .. » et sans nom dans l'UI, fichiers invisibles — Gravité : Mineur</summary> - Où : `POST /api/files` / `PATCH /api/files/{key}/name` : seule validation = longueur 1..255. Le front attend des noms de la forme `/dossier/fichier`. Un fichier nommé `noslash.txt` ou `../x.txt` ne commence pas par `/` donc n'apparaît dans aucun dossier (`useFileBrowser.ts` filtre `startsWith(currFolder)`), et `getRecentFiles` (`files.api.ts`) ne retient que les noms commençant par `/`. - Obtenu (UI, vérifié) : à la racine de /knowledge, `//qa_files_double.txt` crée une ligne de dossier SANS nom, `/../../etc/passwd` crée un dossier nommé `..` (confondable avec le bouton « remonter ») ; `noslash.txt` / `../qa_files_dotdot.txt` n'apparaissent nulle part (invisibles, non supprimables par l'UI). Preuve : `screens/qa_files_12_root_weird_and_long.png`. - Cause probable : validation serveur limitée à `[Length(1,255)]` (`Storage/Upload/UploadFileEndpoint.cs:14`, `Update/UpdateFileNameEndpoint.cs:10`) ; la convention « /dossier/nom » n'est vérifiée que côté front (`FileUpload.tsx`). </details> <details><summary>[FILES-09] Aucune unicité de nom : deux fichiers (ou plus) identiques dans le même dossier — Gravité : Mineur</summary> - Uploader deux fois `qa_files_dup.txt` dans le même dossier (UI) -> deux lignes identiques, indiscernables (même taille, même icône, sans date ni auteur affichés) ; idem après un « Move » vers un dossier contenant déjà le même nom. Aucun avertissement. Un renommage vers un nom existant est aussi accepté. (Comportement probablement voulu côté API, mais l'UI ne permet pas de distinguer les doublons.) </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:17 +00:00

asventi self-assigned this

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

asventi closed this issue

2026-10-28 13:20:48 +00:00