5.3 KiB
SEC-05 — Le client reçoit le jeton de réponse du transporteur
Gravité historique : Moyenne. Classification : CWE-863.
État au 14 septembre 2026 : Exposition dans les réponses ordinaires corrigée dans le code suivi : retrait du DTO, du mapper et du type frontend. Les liens envoyés au transporteur conservent leur fonctionnement. Risque résiduel : les tokens déjà copiés ne sont pas invalidés par le changement de sérialisation. Leur révocation ou expiration réelle n'a pas été vérifiée. Voir aussi SEC-07 pour les logs actuels.
Executive Summary
Le créateur d'une réservation peut lire sa réponse métier. Dans l'ancienne version, cette réponse contient également confirmationToken, un secret destiné au transporteur. Un membre accédant à la liste de son organisation pouvait aussi le recevoir ; ce second défaut de visibilité est SEC-12.
Cette fiche repose sur la relecture du code historique accessible et du correctif courant, ainsi que des preuves documentées lors des passes précédentes. Elle ne constate aucun incident réel. La plus ancienne version ici vérifiée est le snapshot 8446f87 ; les corrections historiques figurent dans c09b8be. Aucun tag local ni version déployée n'a permis d'établir une première release vulnérable ou corrigée. Voir METHODOLOGIE.md.
Background
Le token est un credential de décision transporteur, et non une simple métadonnée de réservation. Le demandeur et le transporteur sont deux autorités différentes même s’ils interviennent sur le même dossier.
Vulnerability Details
CsvBookingService.toResponseDto sérialise le token avec le statut et les documents. Les routes publiques GET /api/v1/csv-booking-actions/accept/:token et reject/:token utilisent ce même secret pour retrouver puis accepter ou refuser la réservation. Le demandeur possède alors l'autorité censée appartenir au transporteur, sans avoir accès à sa boîte mail. Le domaine impose cependant un statut compatible, une absence d'expiration et une réservation encore non résolue. La protection documentaire par mot de passe ne s'applique pas à la décision d'acceptation.
Extrait historique vérifié, apps/backend/src/application/services/csv-booking.service.ts, lignes 1608–1612 du snapshot préaudit :
status: booking.status,
documents: booking.documents.map(this.toDocumentDto),
confirmationToken: booking.confirmationToken,
requestedAt: booking.requestedAt,
respondedAt: booking.respondedAt || null,
Les numéros ci-dessus décrivent le snapshot ancien ; les liens suivants ouvrent les fichiers courants, où les lignes peuvent avoir changé.
Sources à examiner ensemble :
- apps/backend/src/application/services/csv-booking.service.ts
- apps/backend/src/application/controllers/csv-booking-actions.controller.ts
- apps/backend/src/domain/entities/csv-booking.entity.ts
Exploitability Analysis
Fausse décision transporteur et effets métier associés sur la réservation accessible à l'attaquant. Cela ne permet pas, à lui seul, de lire toutes les réservations, de contourner le paiement préalable, ni de télécharger les documents protégés par un mot de passe. La possession d'un secret valide reste indispensable.
Le code applicatif établit le chemin décrit, mais ne renseigne pas les protections effectives d'un déploiement donné, sa version en ligne ou les accès déjà exercés par un attaquant. La gravité ci-dessus est celle du mécanisme vulnérable avant correction ; elle n'est pas un score de risque résiduel calculé pour la production.
Proof of Concept
Tests de non-régression existants, inspectables dans le dépôt :
Ils testent les refus et les usages autorisés avec des données locales. Ils ne prouvent pas qu'une ancienne exploitation a eu lieu en production. Les commandes et résultats consolidés sont dans VALIDATION.md ; aucun nouvel exploit n'a été exécuté pendant la rédaction.
Remediation
Exposition dans les réponses ordinaires corrigée dans le code suivi : retrait du DTO, du mapper et du type frontend. Les liens envoyés au transporteur conservent leur fonctionnement. Risque résiduel : les tokens déjà copiés ne sont pas invalidés par le changement de sérialisation. Leur révocation ou expiration réelle n'a pas été vérifiée. Voir aussi SEC-07 pour les logs actuels.
Pour solder le constat en exploitation, vérifier le comportement sur la version effectivement déployée et conserver les contrôles légitimes décrits. La présente passe ajoute uniquement de la documentation ; les correctifs mentionnés existaient avant sa rédaction.
Summary
Le client reçoit le jeton de réponse du transporteur est un constat historique de l'audit, à lire avec son état courant ci-dessus. La preuve porte sur le mécanisme et les contrôles cités ; elle ne constitue ni une attestation d'exploitation réelle ni une certification exhaustive du projet.