Votre formulaire de réinitialisation de mot de passe est un canon à e-mails gratuit
Le formulaire de réinitialisation de mot de passe est probablement l'endpoint le moins intéressant que vous possédez. C'est aussi le seul qu'un attaquant peut pointer vers n'importe qui. Le nôtre n'a eu aucune limitation de débit par e-mail pendant un moment, et la raison pour laquelle cela compte n'est pas celle que vous imagineriez.
Le réflexe, quand vous entendez « endpoint non authentifié, pas de limitation de débit », c'est de penser à la force brute. Mais il n'y a rien à forcer sur une demande de réinitialisation. Vous ne devinez pas un mot de passe. Vous soumettez une adresse e-mail et le système envoie un lien. Le marteler ne vous fait entrer dans aucun compte. Alors qui trinque ?
La victime est un tiers. Tapez l'adresse de quelqu'un d'autre, [email protected], appuyez sur envoyer, recommencez. Chaque requête envoie un vrai e-mail à une vraie boîte de réception que vous ne contrôlez pas. Vous avez enrôlé notre formulaire de réinitialisation dans une bombe à e-mails visant quelqu'un qui ne s'est jamais inscrit à quoi que ce soit. Et parce que le courrier vient de nous, les dégâts atterrissent à deux endroits à la fois. La boîte de réception de la victime se remplit. Et notre réputation d'expéditeur en prend un coup, car un déluge de courrier indésirable depuis notre domaine est exactement ce que les fournisseurs de messagerie surveillent. Assez de cela et notre courrier légitime, les liens de vérification, les vraies réinitialisations de mot de passe, commence à atterrir dans les spams pour chaque client réel que nous avons. Un endpoint non authentifié, sans identifiants et sans coût pour l'attaquant, dégrade une ressource que tous nos utilisateurs partagent.
Alors vous le limitez en débit. Par adresse e-mail, pour qu'une cible ne puisse pas être inondée. Facile. Sauf que l'implémentation évidente ouvre discrètement une autre faille.
Si vous n'appliquez la limite, ou ne faites le travail, que lorsque l'adresse possède réellement un compte, alors l'endpoint se comporte différemment pour les vrais comptes et pour les comptes inventés. Un attaquant capable de voir cette différence, dans la réponse, le code de statut, ou simplement le timing, dispose désormais d'un oracle pour savoir quelles adresses e-mail sont enregistrées chez vous. Les formulaires de réinitialisation sont une fuite classique d'énumération de comptes pour exactement cette raison : la solution naïve à la bombe à e-mails crée le bug d'énumération.
La vraie solution doit faire les deux choses à la fois, et les deux moitiés sont distinctes. Premièrement, limitez le débit sur l'adresse e-mail normalisée, qu'un compte existe ou non. La clé de limitation est l'adresse elle-même, mise en minuscules et débarrassée des espaces pour que Victim@ et victim@ partagent un même seau, et le compteur est appliqué avant d'avoir consulté quoi que ce soit. Ce compteur doit vivre dans un stockage partagé et durable, pas dans la mémoire d'un seul processus, sinon il s'évapore à un redémarrage et ne fait rien à travers plusieurs instances. Deuxièmement, répondez à l'identique dans tous les cas : le même statut, le même message « si cette adresse possède un compte, nous avons envoyé un lien », le même profil temporel, que l'adresse soit l'une des vôtres ou non. Vous n'envoyez toujours de courrier que lorsqu'il y a un compte derrière. Mais rien de ce qu'un observateur extérieur peut voir ne change en fonction de ce secret. La limitation de débit protège le tiers ; la réponse constante protège le fait de savoir qui possède un compte.
La leçon générale dépasse les réinitialisations de mot de passe. Tout endpoint non authentifié qui provoque un effet de bord dans le monde réel, envoyer un e-mail, envoyer un SMS, appeler un webhook, ne fait pas simplement partie de votre surface d'attaque. C'est une arme braquée sur celui qui se trouve à l'autre bout, et la facture pour l'avoir tirée atterrit sur votre réputation, pas sur celle de l'attaquant. Limitez le débit selon la chose sur laquelle on agit, c'est-à-dire le destinataire, pas l'appelant. Et faites-le sans laisser la présence ou l'absence d'un état secret changer ce que voit un observateur.
Le formulaire de réinitialisation de mot de passe a des airs de plomberie. C'est le seul morceau de plomberie qui arrosera joyeusement n'importe qui dans le monde sur commande. Régulez son débit en conséquence.
Réguler le débit d'un endpoint à effet de bord non authentifié sans révéler qui possède un compte est plus délicat qu'il n'y paraît. Authagonal livre le flux de réinitialisation déjà limité en débit et protégé contre l'énumération, pour que votre réputation d'expéditeur ne soit jamais à une seule boucle curl de la ruine.