Surface réduite, revue publiée
Missivus détient un identifiant capable d'envoyer des e-mails au nom de votre entreprise. C'est exactement le genre de code qui doit être relu ligne par ligne et documenté publiquement — c'est donc ce qui a été fait.
Le modèle de sécurité en un paragraphe
La stratégie d'accès aux applications d'Exchange est ce qui borne le rayon d'impact. Chaque constat ci-dessous est contenu par elle — même un identifiant entièrement compromis ne peut qu'envoyer au nom d'une seule boîte aux lettres partagée, et rien d'autre. C'est pourquoi le guide d'installation traite la stratégie comme une étape obligatoire assortie d'une commande de vérification, et non comme un durcissement optionnel.
Ce que la revue a couvert
L'arborescence v0.1.1 a été auditée après le premier déploiement en production — le transport Graph, le modèle de paramètres, la méthode d'API d'e-mail de test et le composant Vue, contrôlés contre les fuites de secrets via les journaux, les réponses d'API, le code HTML et la console du navigateur ; l'authentification et la protection CSRF de la surface d'API ; la validation des entrées sur chaque paramètre ; et la possibilité qu'un corps d'erreur Graph atteigne quelqu'un d'autre qu'un super-utilisateur. Les affirmations sur le comportement de Matomo ont été vérifiées dans le code source de Matomo, pas de mémoire.
Constats, énoncés honnêtement
Corrigés avant publication
- Une redéfinition de l'URL de base aurait pu diriger le secret client vers l'hôte d'un attaquant — les URL sont désormais validées comme de simples origines https avant toute construction de requête.
- Une panne réseau en cours d'envoi pouvait laisser fuiter une URL d'envoi pré-authentifiée dans le journal — désormais convertie et caviardée comme tout autre échec.
- Les paramètres acceptaient n'importe quelle chaîne — chaque champ valide désormais son format, si bien qu'un Secret ID collé par erreur échoue dès l'enregistrement, et non plus tard sous la forme d'une erreur Microsoft opaque.
- La méthode d'API d'e-mail de test acceptait n'importe quel destinataire et répondait au GET — désormais en POST uniquement, avec une adresse validée, tenue à l'écart des journaux d'accès du serveur.
Vérifiés sains
- Les secrets n'atteignent jamais le code HTML, les réponses d'API ni la console du navigateur — les champs de mot de passe sont masqués par le cœur de Matomo, et le plugin ajoute deux garde-fous supplémentaires.
- L'appel de test est protégé contre les CSRF par le modèle de jetons de Matomo, avec une règle POST uniquement ajoutée en défense en profondeur.
- Tout ce qui est journalisé ou levé passe par un caviardeur qui masque les secrets connus par leur valeur et les identifiants par leur forme — jetons, assertions, en-têtes bearer, URL d'envoi — et qui échoue de manière sûre.
Compromis acceptés, documentés
- Le jeton d'accès à courte durée de vie est mis en cache dans le cache sur fichiers de Matomo — quiconque peut le lire peut déjà lire la configuration de Matomo, qui peut elle-même contenir le secret. Atténué par la durée de vie de 55 minutes et la stratégie d'accès.
- Un super-utilisateur peut envoyer des e-mails de test sans limitation — un vecteur de nuisance, pas d'élévation de privilèges ; un super-utilisateur pourrait de toute façon reconfigurer entièrement la messagerie.
- Un secret saisi dans l'interface des paramètres est stocké non chiffré dans la base de données de Matomo — les niveaux fichier de configuration et variables d'environnement existent précisément pour qu'il n'ait jamais à l'être, et ils sont prioritaires.
Signaler une vulnérabilité
Écrivez à l'adresse ci-dessous en détaillant le problème. Merci de nous laisser la possibilité de le corriger avant qu'il ne devienne public — et n'incluez jamais de secret client, de certificat ou de fichier PEM dans un signalement.
Contact sécurité:…