Le nom d'un fichier détruit pouvait rester lisible avec son lien et une copie de son contenu
Lire un fichier demande trois éléments : son contenu chiffré, son vecteur d'initialisation et sa clé, qui voyage dans le lien. À la lecture ou à l'échéance, le contenu et le vecteur sont détruits : même avec le lien, le fichier ne peut plus être déchiffré.
Le nom et le type du fichier, chiffrés avec la même clé, échappaient toutefois à cette règle. Une personne qui aurait conservé une copie de leur chiffré, ce qui suppose un accès à nos serveurs, et qui aurait aussi obtenu le lien aurait pu les lire après la destruction du fichier, mais pas son contenu. Cela valait avec ou sans chiffrement de bout en bout.
Le nom et le type d'un fichier dépendent désormais eux aussi d'un vecteur détruit à la lecture, distinct de celui du contenu.
Connexion sans effet avec Chrome hors de l'adresse de son organisation
Une organisation peut être servie à sa propre adresse. Un utilisateur qui se connectait ailleurs devait y être renvoyé pour se reconnecter : avec Chrome et les navigateurs qui en dérivent, comme Edge, ce renvoi n'avait pas lieu, et le bouton « Se connecter » restait sans effet. Un invité qui saisissait son jeton hors de l'adresse de l'organisation qui l'avait invité était dans le même cas.
Le renvoi fonctionne désormais avec tous les navigateurs.
Un message détruit pouvait rester déchiffrable avec son lien et une copie de son contenu
Lire un message demande trois éléments : son contenu chiffré, son vecteur d'initialisation et sa clé, qui voyage dans le lien. À la lecture ou à l'échéance, le contenu et le vecteur sont détruits : même avec le lien, le message ne peut plus être déchiffré.
Pour un message envoyé sans chiffrement de bout en bout, le vecteur pouvait toutefois être recalculé. Une personne qui aurait conservé une copie de son contenu chiffré, ce qui suppose un accès à nos serveurs, et qui aurait aussi obtenu son lien aurait donc pu le lire après sa destruction.
Le vecteur est désormais tiré au hasard : une fois détruit, rien ne permet plus de le retrouver.
Exploitation : Aucune exploitation constatée dans nos journaux.
Journal d'activité : actions sur les jetons invités manquantes
Depuis juillet, le journal d'activité n'enregistrait plus la création ni la suppression des jetons d'invitation. Il omettait aussi la déclaration et le retrait d'un domaine personnalisé au nom très long.
Ces actions y figurent de nouveau. Un jeton y est désigné par le même début d'empreinte que sur la page des jetons ; les entrées plus anciennes, qui montraient la valeur d'un jeton expiré depuis, ne l'affichent plus.
Protection contre les tentatives répétées contournable en IPv6
Depuis une connexion IPv6, une personne qui changeait d'adresse à chaque essai pouvait échapper au blocage des tentatives de connexion répétées et à la limitation du nombre de requêtes, et multiplier ainsi les essais de mot de passe.
Ces protections s'appliquent désormais à l'ensemble des adresses attribuées à une même connexion IPv6.
Exploitation : Aucune exploitation constatée dans nos journaux.
Les fichiers volumineux ne pouvaient pas être envoyés
Au-delà de quelques dizaines de mégaoctets, bien en deçà de la taille annoncée, l'envoi d'un fichier échouait sur une erreur du serveur. Un fichier que le serveur n'avait pas pu recevoir en entier aboutissait lui aussi à une erreur, sans explication.
La taille annoncée est désormais tenue, à l'envoi comme au téléchargement, avec ou sans chiffrement de bout en bout. Un fichier mal reçu est refusé, avec un message qui en donne la raison.
Messages d'invités : cloisonnement entre organisations
Un invité pouvait, à condition de connaître l'identifiant d'un message, consulter le dossier de signature d'un message envoyé par l'invité d'une autre organisation : identité, numéro de mobile et signature manuscrite du signataire.
Chaque contrôle d'accès à un message vérifie désormais l'organisation de la session, et les invités n'ont plus d'identité commune d'une organisation à l'autre.
Exploitation : Aucune exploitation constatée dans nos journaux.
Un message pouvait être envoyé sans jamais pouvoir être lu
Lorsque le service cryptographique ne répondait pas correctement, l'envoi semblait réussir et un lien était remis, mais le message ne pouvait jamais être ouvert.
L'envoi est désormais refusé, avec un message indiquant que le service de chiffrement est momentanément indisponible.
Le formulaire d'inscription pouvait servir à écrire à des tiers
En saisissant l'adresse d'un tiers dans le formulaire d'inscription, n'importe qui pouvait lui faire envoyer, depuis notre domaine, des e-mails reprenant un texte libre (raison sociale, prénom).
Les e-mails d'inscription ne reprennent plus rien de la saisie, une même adresse n'en reçoit qu'un par 24 heures, et les inscriptions sont suspendues le temps qu'un afflux anormal retombe.
Exploitation : Aucune exploitation constatée dans nos journaux.
Les invités d'une organisation suspendue gardaient l'accès
Après la désactivation ou la suspension d'une organisation, ses invités pouvaient encore, pendant 24 heures au plus, envoyer des messages en son nom et consommer ses SMS. Supprimer un lien d'invitation ne fermait pas non plus la session déjà ouverte avec lui.
Une session invitée est désormais fermée dès que son organisation ou l'utilisateur qui a invité est désactivé, ou que le lien d'invitation est supprimé.
Exploitation : Aucune exploitation constatée dans nos journaux.
Domaine d'organisation : des liens envoyés vers un domaine qui n'était plus le sien
Si le domaine personnalisé d'une organisation cessait de pointer vers One Shot Message (domaine expiré puis racheté par un tiers, par exemple), les liens de lecture, de réinitialisation et d'invitation continuaient d'y être envoyés. Un domaine déclaré mais jamais vérifié restait en outre réservé sans limite de temps. La fonction était en service depuis le 29 septembre.
Un domaine en écart est désormais mis de côté aussitôt : les liens repassent sur oneshotmessage.fr jusqu'à ce qu'il redevienne conforme, et l'administrateur de l'organisation en est prévenu. Une déclaration non vérifiée est retirée au bout de 30 jours.
Exploitation : Aucune exploitation constatée dans nos journaux.
Des mots de passe provisoires envoyés par e-mail
Un compte créé par un administrateur, le nôtre ou celui de l'organisation, recevait par e-mail un mot de passe provisoire, à changer à la première connexion.
Il reçoit désormais un lien à usage unique, valable 72 heures, pour choisir lui-même son mot de passe : aucun mot de passe ne transite plus par e-mail.
Exploitation : Aucune exploitation constatée dans nos journaux.
Des journaux conservés au-delà de la durée annoncée
La purge automatique s'interrompait en cours de route : des journaux techniques (connexions, mesure d'audience, pare-feu, notifications de webhook) et des comptes supprimés étaient conservés au-delà de la durée annoncée par notre politique de confidentialité.
Chaque étape de la purge s'exécute désormais indépendamment des autres, et les durées de conservation techniques sont ramenées à douze mois, comme l'annonce cette politique.
Des liens complets dans des journaux internes
Certains journaux techniques internes (mesure d'audience, erreurs) enregistraient en entier des liens de lecture, de réinitialisation de mot de passe et d'invitation. Une personne ayant accès à ces journaux aurait pu s'en servir pour ouvrir un message non encore lu, envoyé sans chiffrement de bout en bout, réinitialiser un mot de passe dans l'heure ou ouvrir une session invitée.
Ces liens y sont désormais masqués, y compris dans les enregistrements antérieurs.
Exploitation : Aucune exploitation constatée dans nos journaux.
Accusé de lecture des fichiers jamais envoyé
Pour un fichier envoyé sans chiffrement de bout en bout, l'expéditeur qui demandait à être prévenu de la lecture ne recevait pas l'e-mail. Il est désormais envoyé.
Fichier à signer : téléchargement impossible après la signature
Le destinataire d'un fichier soumis à signature était ramené à l'écran de signature après avoir signé, sans pouvoir télécharger le fichier. Le téléchargement suit désormais la signature.
Corrections mineures issues de la revue de sécurité
- Le logo de l'organisation ne peut plus être changé que par son administrateur, et le fichier envoyé est contrôlé.
- La suppression d'un message par l'API détruit aussitôt son contenu chiffré, qui attendait jusque-là la purge annuelle.
- Les adresses e-mail sont validées à la création et à la modification d'un utilisateur : une adresse mal formée pouvait perturber l'envoi d'un e-mail.
- Le nom d'un fichier choisi pour un envoi, ou comme logo de l'organisation, s'affichait sans précaution : un nom piégé pouvait modifier la page, mais seulement dans le navigateur de la personne qui choisissait ce fichier. Il s'affiche désormais comme du simple texte.
Exploitation : Aucune exploitation constatée dans nos journaux.
Webhooks : des notifications détournables vers des machines non publiques
Un client de l'API pouvait faire adresser nos notifications de webhook à des machines qui ne sont pas accessibles depuis Internet. Ces notifications ne transportent aucun contenu de message.
L'adresse de destination est désormais vérifiée à chaque envoi.
Exploitation : Aucune exploitation constatée dans nos journaux.
Un message à usage unique pouvait être lu deux fois
Deux ouvertures strictement simultanées du même lien pouvaient chacune afficher le contenu, alors qu'une seule lecture est permise. Il fallait détenir le lien.
La lecture est désormais exclusive : la seconde ouverture trouve le message déjà détruit.
Exploitation : Aucune exploitation constatée dans nos journaux.
Certaines adresses échappaient aux contrôles
Des requêtes formulées d'une certaine manière échappaient au filtrage des paramètres attendus par chaque page, à la protection contre les requêtes intersites forgées (CSRF) et, pour une partie d'entre elles, à l'inspection du pare-feu applicatif.
Ces formes d'adresse sont désormais refusées, ou contrôlées comme les autres.
Exploitation : Aucune exploitation constatée dans nos journaux.
Des sessions survivaient à un changement de mot de passe
Changer ou réinitialiser son mot de passe, choisir « Se déconnecter partout », ou voir son compte désactivé ou supprimé ne fermait que les connexions mémorisées (« Rester connecté sur cet appareil »). Les sessions déjà ouvertes restaient valides jusqu'à leur expiration.
Elles sont désormais fermées dès la requête suivante.
Exploitation : Aucune exploitation constatée dans nos journaux.
Codes SMS : trop d'essais permis
Les codes à usage unique du verrou SMS et de la signature n'étaient limités qu'en nombre d'essais par adresse IP. Quelqu'un qui détenait déjà le lien et disposait de nombreuses adresses pouvait multiplier les tentatives.
Un code est désormais annulé après cinq essais erronés ; il faut alors en demander un nouveau.
Exploitation : Aucune exploitation constatée dans nos journaux.
Le verrou SMS pouvait ne pas être posé
Un message pour lequel l'expéditeur avait demandé un code SMS pouvait partir sans ce verrou, en particulier avec le chiffrement de bout en bout, proposé par défaut : il s'ouvrait alors avec le seul lien. Le cas se présentait aussi avec un numéro invalide ou une offre sans SMS.
Quand le verrou demandé ne peut pas être posé, l'envoi est désormais refusé et le motif affiché.
Exploitation : Aucune exploitation constatée dans nos journaux.
