fix(security): correction de 8 vulnérabilité

[TiotBenjy]

Contexte

Revue de sécurité complète de l'application, backend & frontend + déploiement Docker Compose.

8 sont corrigées ici, une par commit. Pour chacune, les tests ont été écrits avant le correctif et vérifiés et rouges.

Correctifs

#	Sévérité	Vulnérabilité	Correctif
1	Medium, impact technique élevé	SSTI menant à une RCE dans les templates email. Les trois environnements Jinja2 rendant du contenu fourni par l'utilisateur étaient des Environment nus. POST /templates/{name}/preview renvoyait la sortie dans la réponse, soit un oracle de RCE direct atteignant la clé GPG de signature du dépôt et JWT_SECRET_KEY	SandboxedEnvironment aux trois points de rendu. autoescape n'échappe que la sortie, il ne restreint pas la traversée d'attributs
2	Medium	Path traversal par le champ group de l'import APT. Un rôle uploader, typiquement un jeton de CI, écrivait un .deb hors de IMPORTS_DIR, y compris dans les bind mounts en écriture /repos/gnupg, /repos/db et /repos/conf	safe_path_join au sink, avant le téléchargement, couvrant les trois appelants, plus un contrôle de frontière renvoyant 400 avant l'ouverture du flux SSE
3	Medium	Le rôle d'autorisation venait du claim JWT, pas de la base. 118 points de décision concernés, et POST /auth/refresh recopiait le claim périmé dans un jeton neuf toutes les 45 minutes : rétention indéfinie de droits révoqués	Une ligne dans _parse_token : le rôle est relu dans la table users à chaque requête. Le refresh est corrigé mécaniquement, get_current_user_full retournant ce même dict
4	Medium	/metrics anonyme exposant des données nominatives. Le chemin brut servait de label Prometheus, mettant noms d'utilisateurs, couples paquet/version et identifiants de groupe dans le registre. Le garde était un if sans else	Anonymisation du label en gabarit de route, plus une échelle de créance à trois niveaux. C'est l'anonymisation qui retire la vulnérabilité
5	Medium	Wildcard CORS avec credentials par défaut. docker compose up depuis un clone propre livrait allow_origins=["*"] avec allow_credentials=True	Refus du wildcard au démarrage, levée en production, et défaut de compose ramené à l'origine explicite que .env.example recommandait déjà
6	Medium	POST /packages/install/ atteignable par le rôle reader. Il déclenchait une exécution SSH sur la machine gérée, injectant un paquet amont et sa fermeture de dépendances dans le pool servi, sans audit	Suppression de l'endpoint, doublon hérité de POST /artifacts/{name}/install qui porte le garde, le contrôle de dépendances et l'audit
7	Medium bas	Annuaire du personnel lisible par le rôle le moins privilégié. GET /groups/{id}/members renvoyait nom complet, adresse e-mail et rôle de chaque membre à tout compte authentifié	get_admin_user sur la route, alignant la lecture sur l'écriture. Le bouton frontend qui offrait cette lecture aux non-admins est retiré
8	Low	.. accepté dans la suppression d'un groupe d'import. La regex ^[\w.\-+]+$ contient un point littéral, rmtree effaçait alors le contenu du dépôt	safe_path_join, refus explicite du chemin résolvant vers la base, et is_dir() à la place de exists()

Décisions de conception

Le rôle reader est un "compte de service". auth/users.py le documente comme distribué à chaque machine cliente APT. C'est ce qui fait passer les vulnérabilités 6 et 7 d'un problème théorique de RBAC à une exposition réelle : le jeton du rôle le plus bas est présent sur tout le parc.

Confinement sémantique plutôt que validation syntaxique. Les vulnérabilités 2 et 8 sont toutes deux corrigées par safe_path_join, jamais par une regex. Celle qui existait dans le code, ^[\w.\-+]+$, acceptait . et .., vérifié par exécution. Toute classe de caractères assez large pour les noms Debian réels (g++, libssl1.1, foo.bar-1+deb) laisse passer les segments de points.

Un helper de confinement encode un prédicat, pas une intention. La vulnérabilité 8 a demandé un refus de . en plus de safe_path_join. Où l'opération était une écriture dans le répertoire de base. Une suppression demande un descendant strict. Le contrôle est ajouté au point d'appel, pas au helper partagé, dont les autres appelants acceptent légitimement ce cas.

Retirer la donnée sensible plutôt que restreindre l'accès. Sur la vulnérabilité 4, fermer /metrics aurait cassé les scrapes existants, rendu fausses deux lignes de documentation et cassé trois tests, tout en laissant les identifiants dans les labels pour qui détient le jeton. Anonymiser les labels supprime la fuite sans rien casser, et le mode strict garde son enforcement.

Impact opérationnel

Six changements sont visibles en exploitation.

1. Un déploiement ayant explicitement défini CORS_ORIGINS=* refusera de démarrer en production. Le message indique quoi définir. C'est la posture des quatre blocs de validation déjà présents dans main.py.
2. POST /api/v1/packages/install/ renvoie désormais 404. Aucun appelant dans le frontend ni dans la documentation. Le chemin légitime est POST /api/v1/artifacts/{name}/install.
3. GET /api/v1/groups/{id}/members renvoie 403 hors admin.
4. Les changements de rôle prennent effet immédiatement, rétrogradation comme promotion, sans attendre l'expiration du jeton. L'interface d'un utilisateur rétrogradé reste optimiste au plus 45 minutes, mais chaque appel derrière les boutons affichés renvoie 403.
5. Le label path de /metrics change de forme, du chemin concret vers le gabarit de route. Un serveur Prometheus ayant déjà scrapé les séries à chemin brut les conserve dans son TSDB pour sa durée de rétention : les purger relève de son API admin, pas de ce correctif.
6. Quand METRICS_TOKEN est défini, un JWT de rôle auditeur devient une créance alternative acceptée sur /metrics. Le rôle est relu en base, un claim falsifié est refusé.