4.9 KiB
SEC-15 — SMTP : identité du serveur non vérifiée et STARTTLS facultatif
Gravité : Moyenne, avant correction.
État au 14 septembre 2026 : Corrigé dans le code suivi ; configuration de production à confirmer.
Executive Summary
Un intermédiaire actif sur le trajet réseau entre le backend et le serveur SMTP pouvait présenter un certificat non approuvé. Lorsque le transport utilise STARTTLS plutôt que TLS implicite, il pouvait aussi supprimer ou refuser l'annonce STARTTLS. Il faut contrôler le réseau ou le serveur contacté ; un simple utilisateur du site n'obtient pas cette capacité.
Le snapshot préaudit 8446f87 est la version vulnérable vérifiée ; le correctif est présent dans c09b8be. Aucun tag local ni version de production vérifiée ne permet d'annoncer une première release affectée ou une release déployée corrigée. La validation combine relecture du source et tests locaux documentés ; aucun incident réel n'est affirmé.
Background
La frontière de sécurité est celle décrite par les prérequis ci-dessus. Le paramétrage fourni par le dépôt ne permet pas de connaître la topologie et les valeurs effectivement en ligne. Les preuves disponibles doivent donc être lues séparément des conditions de déploiement restant à vérifier.
Vulnerability Details
EmailAdapter.buildTransporter construit l'unique transport Nodemailer. Dans le snapshot 8446f87, l'option TLS est explicitement rejectUnauthorized: false et requireTLS est absent. Le nom SMTP reste configuré, mais sans validation de chaîne il ne suffit pas à authentifier le serveur. Pour un port en mode STARTTLS avec secure=false, l'absence d'obligation de chiffrement laisse en outre possible une authentification en clair si le serveur n'offre pas STARTTLS. Les emails contiennent notamment des liens d'invitation et de récupération : l'identité du relais protège à la fois le credential SMTP et ces messages.
Sources courantes, fonctions et tests concernés :
- apps/backend/src/infrastructure/email/email.adapter.ts
- apps/backend/src/infrastructure/email/email.adapter.spec.ts
Pour comparer au snapshot vulnérable, consulter ces mêmes chemins dans la révision citée, sans supposer que les numéros de lignes actuels correspondent à l'ancienne version.
Exploitability Analysis
La perte de confidentialité concerne les messages et l'authentification lorsque les prérequis réseau sont réunis. Aucun fournisseur SMTP réel n'a été contacté et aucun email n'a été intercepté. L'acceptation d'une chaîne de confiance arbitraire est établie par la configuration ; le test dynamique disponible démontre le refus du déclassement STARTTLS après correction, pas une interception TLS de bout en bout avant correction.
Le problème ne requiert pas de supprimer les contrôles métier ou cryptographiques voisins. Il exploite précisément la différence entre le contrôle attendu et celui effectivement exécuté. Les contre-exemples ci-dessous précisent ce que les tests isolent ; ils ne constituent pas un test de pénétration du site en ligne.
Proof of Concept
Quatre tests sont documentés dans la passe du 10 septembre. Un serveur éphémère loopback refusant STARTTLS est rejeté avant AUTH en production ; le contrôle explicitement en développement peut s'authentifier. Les options de certificat et le nom original sont inspectés, tandis que l'erreur de certificat SMTP est simulée. Aucun message réel n'est envoyé.
Les artefacts sont déjà dans les fichiers de test liés ci-dessus. Aucun faux journal d'exploitation ni nouvelle commande d'attaque de production n'est fourni. Voir VALIDATION.md pour le périmètre et les résultats consolidés.
Remediation
La version courante active rejectUnauthorized: true, conserve le nom original pour vérifier le certificat après résolution IP et exige requireTLS lorsque NODE_ENV vaut exactement production. Un environnement nommé autrement conserve la politique de développement concernant STARTTLS : vérifier les valeurs de déploiement sans supposer que le nom commercial « préproduction » configure automatiquement NODE_ENV. Le TLS implicite reste supporté. Le test local autorise explicitement le SMTP sans TLS en développement, ce qui n'est pas une politique à transposer en production.
La présente passe documente ce changement antérieur ; elle n'ajoute aucun correctif applicatif et ne confirme pas son déploiement.
Summary
Le mécanisme décrit est confirmé dans la révision vulnérable citée, et la portée du correctif local est bornée par les tests disponibles. Corrigé dans le code suivi ; configuration de production à confirmer. Les limites de couverture générale sont détaillées dans COUVERTURE.md.