Quelle que soit l’application web, il est courant de permettre aux utilisateurs de changer leur adresse email. Cette fonctionnalité est critique car elle impacte directement la gestion des comptes. De plus, l’adresse email sert souvent d’identifiant pour l’authentification. Il est donc essentiel de sécuriser cette fonctionnalité.
Nous pouvons distinguer différentes situations. Dans certains cas, l’application permet aux utilisateurs de changer leur propre adresse email. D’autres fois, un administrateur peut modifier les adresses email des utilisateurs. Parfois, les deux options sont possibles.
Dans cet article, nous détaillerons les bonnes pratiques à suivre. Nous examinerons ensuite des cas concrets de mauvaises configurations rencontrées lors d’audits, puis nous donnerons des exemples d’attaques.
Quelles sont les bonnes pratiques d’implémentation de la fonctionnalité de changement d’email ?
Même s’il existe des solutions spécifiques en fonction du contexte et des besoins sécurité, voici les bonnes pratiques générales à mettre en place.
L’utilisateur change sa propre adresse email
Encore une fois, cette fonctionnalité est critique. Nous recommandons de demander à l’utilisateur qui souhaite changer son adresse email d’entrer son mot de passe (ou un code 2FA) lors de la requête.
Et le mot de passe envoyé avec la requête de changement d’email doit être vérifiée côté serveur. Cela garantit que la requête provient bien de l’utilisateur légitime.
Après validation du mot de passe, il est essentiel de vérifier que l’utilisateur modifie bien son propre compte. Cette vérification doit également se faire côté serveur.
Ensuite, un email doit être envoyé à la nouvelle adresse fournie. Cependant, il est important de s’assurer que cette adresse a un format valide.
L’email doit permettre de valider que l’utilisateur a accès à cette nouvelle adresse. Par exemple, il peut contenir une URL avec un jeton unique, valide pour une durée limitée.
Enfin, suite au clic de l’utilisateur, la nouvelle adresse email est validée. Et ce n’est qu’à ce moment-là que l’adresse email associée au compte est changée en base de données.
Après utilisation, le jeton doit être révoqué côté serveur. Si l’email de confirmation n’est jamais utilisé, la nouvelle adresse email ne doit pas être prise en compte.
Remarque : Dans la mesure du possible, nous recommandons également d’appliquer la confirmation de l’adresse email lors de la création de compte. Cela garantit que l’utilisateur possède bien un accès à la boîte email indiquée. Dans tous les cas, l’idéal est de ne pas fournir l’accès à l’application web tant que l’email n’a pas été validé.
Un administrateur change l’adresse email d’un utilisateur
Pour les comptes privilégiés de type administrateur, nous recommandons de forcer l’utilisation systématique du 2FA. Lorsqu’un administrateur change l’adresse email d’un autre utilisateur, un code 2FA doit être demandé pour valider la modification.
Les règles suivantes doivent être appliquées :
- L’utilisateur effectuant le changement ne doit pas pouvoir modifier l’email d’un utilisateur plus privilégié ou ayant le même niveau de privilège. La modification doit se faire uniquement sur un utilisateur moins privilégié.
- L’utilisateur effectuant le changement doit avoir accès à toutes les organisations de l’utilisateur concerné et disposer des droits d’administration sur chacune de ces organisations. Sinon, la requête de changement doit être refusée.
Si ces règles sont respectées, l’utilisateur concerné doit recevoir un email à la nouvelle adresse pour confirmer qu’il y a bien accès. L’email peut suivre la procédure décrite précédemment. Une fois l’accès à la boîte email confirmé par le clic sur l’URL de confirmation, le changement peut être pris en compte. Si la nouvelle adresse email n’est jamais validée, l’ancienne adresse doit rester associée au compte.
Exemples de configurations de changement d’email rencontrés lors de pentests
Au cours de nos audits d’applications web, nous avons rencontré plusieurs cas de mauvaises configurations. Voici une liste de ces configurations avec des références aux scénarios d’attaque décrits dans la section suivante.
Aucun contrôle sur le changement d’emails
Il s’agit du cas le plus problématique, où l’application web permet de changer l’adresse email d’un compte sans effectuer de contrôle. Un utilisateur peut donc changer son email ou celui d’autres utilisateurs sans validation de l’accès à la nouvelle adresse email.
Cela pose des problèmes de sécurité et de gestion des comptes. En effet, rien ne garantit que l’utilisateur a accès à la nouvelle adresse email.
Heureusement, ce cas d’absence totale de contrôle est de plus en plus rare pour la fonctionnalité de changement d’email sur son propre compte. Cependant, il arrive encore souvent qu’un administrateur change l’email d’un utilisateur qu’il gère sans contrôle.
Les conséquences peuvent varier : vol de comptes, compromission totale des données d’une organisation, etc.
Dans ce cas, l’application est potentiellement vulnérable aux quatre scénarios d’attaque décrits dans la section suivante.
La nouvelle adresse email est validée sans vérification de l’identité
Dans ce cas, la nouvelle adresse email doit être validée par l’utilisateur. Généralement, un email est envoyé à cette nouvelle adresse, contenant un lien ou un code unique pour confirmer que l’utilisateur a bien accès à la boîte email. Le changement d’adresse email ne sera effectif qu’après cette validation.
Bien que cette méthode prouve l’accès à la boîte email, elle ne prévient pas les abus, surtout en cas de problèmes de droits sur la fonctionnalité. Voir les cas 1, 3 et 4 dans la section suivante pour plus de détails.
L’identité de l’utilisateur est validée sans vérification de la nouvelle adresse
Dans cette situation, l’utilisateur qui demande le changement d’email doit prouver son identité, mais n’a pas besoin de valider la nouvelle adresse email.
L’identité est vérifiée en fournissant un secret lors de la demande, comme le mot de passe du compte, la réponse à une question secrète ou un code 2FA. Bien que cette vérification soit une bonne pratique, elle est insuffisante, surtout pour un utilisateur privilégié qui gère d’autres utilisateurs sur une plateforme multi-organisations.
Cela permet le scénario décrit dans le cas 2 de la section suivante. Et en cas de manque de contrôle des droits, les scénarios des cas 1 et 3 sont également possibles.
Validation sur l’ancienne adresse mail mais pas la nouvelle (ou sur les deux)
Dans ce cas, un email de confirmation du changement d’adresse email est envoyé à l’ancienne adresse (et parfois à la nouvelle également). Cet email indique la nouvelle adresse qui sera utilisée. Le changement ne sera effectif que lorsque l’utilisateur aura cliqué sur le lien de validation.
Cette méthode est la plus sécurisée, car elle prouve que l’utilisateur a accès à l’ancienne adresse et l’informe de la nouvelle. Cependant, le principal problème est que l’utilisateur souhaite généralement changer son adresse email parce qu’il n’a plus accès à l’ancienne. En conséquence, cette méthode est rare et souvent peu adaptée aux plateformes web.
Validation de l’identité de l’utilisateur et de la nouvelle adresse email
Il s’agit de la meilleure solution pour une application web. Elle permet d’éviter presque toutes les attaques.
Toutefois, dans le cas d’un utilisateur privilégié qui gère d’autres comptes sur une plateforme multi-tenants; des risques de vol de compte peuvent subsister si certains contrôles ne sont pas appliqués.
Un exemple de ce risque est présenté dans le cas 3 de la section suivante. Le cas 1 est également possible.
Attaques et exploitations de vulnérabilités liées au changement d’email
Problème de droit de type IDOR sur la fonctionnalité de changement d’email
Imaginons une fonctionnalité permettant de changer l’email d’un utilisateur. La requête HTTP pourrait être la suivante :
POST /api/user/21/emailupdate HTTP/2
Host: example.vaadata.com
Cookie : sess_id =whatever
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0
Content-Type: application/json; charset=utf-8
Content-Length: 36
{"password":"mysecret", "new_email":"[email protected]"} Nous pouvons voir dans l’URL que l’identifiant de l’utilisateur est transmis (ici 21). Le mot de passe de l’utilisateur connecté est également demandé.
En revanche, ce mot de passe est associé à la session de l’utilisateur et non à l’identifiant dans l’URL.
Si un problème de droit de type IDOR existe, un utilisateur malveillant pourrait changer l’email d’un autre utilisateur en modifiant l’identifiant dans l’URL (par exemple, en mettant l’ID 22).
Cela conduirait directement au vol du compte portant l’identifiant 22. L’attaquant pourrait spécifier un email qui lui appartient dans la requête de changement, puis utiliser la fonctionnalité d’oubli de mot de passe pour récupérer le lien de changement de mot de passe. De cette manière, il pourrait obtenir un accès à n’importe quel compte.
Ce cas peut paraître trivial, mais il arrive régulièrement. La solution consiste à mettre en place une vérification des droits pour s’assurer que l’utilisateur effectuant la requête possède bien les autorisations nécessaires pour changer l’email d’un autre utilisateur.
Bloquer l’accès à l’application pour un utilisateur légitime
Ce problème survient lorsque l’adresse email fournie n’est pas validée côté serveur.
Un utilisateur peut alors associer n’importe quelle adresse email à son compte, y compris une adresse inexistante mais non la sienne, pour empêcher un autre utilisateur d’accéder à l’application.
Une autre vulnérabilité observée en pentest consiste à changer l’adresse email du compte par celle d’un autre compte déjà existant. Si la modification est acceptée, deux comptes peuvent se retrouver avec la même adresse email, rendant potentiellement un ou les deux comptes inaccessibles lors de l’authentification.
Dans des cas très spécifiques, comme lorsqu’une connexion SSO est possible et que l’authentification par mot de passe est aussi autorisée, cela peut entraîner une vulnérabilité appelée « pre-account takeover ».
Par exemple, si un utilisateur peut se connecter via SSO Google, un attaquant pourrait changer l’adresse email de son propre compte pour celle d’un utilisateur qui n’a pas encore de compte.
Lorsque l’utilisateur légitime utilise SSO pour créer un compte, il est redirigé vers le compte de l’attaquant, car l’adresse email est déjà utilisée. L’utilisateur légitime pense être connecté à son propre compte, tandis que l’attaquant peut se connecter via l’authentification email/mot de passe et accéder aux données de l’utilisateur légitime.
Pour éviter ce problème, il est crucial de valider l’adresse email en demandant à l’utilisateur de cliquer sur un lien unique avant d’accepter le changement. Ainsi, un attaquant ne pourra pas modifier son adresse email pour une adresse à laquelle il n’a pas accès.
Elévation de privilèges dans le cas d’une plateforme avec de nombreuses organisations
Les contrôles sont souvent moins stricts pour les utilisateurs privilégiés, car supposés bienveillants. Cependant, des vulnérabilités importantes peuvent survenir à cause de ce manque de contrôle, surtout dans des environnements multi-tenants où les conséquences peuvent être graves.
Dans cet exemple rencontré plusieurs fois en pentest, il faut imaginer une plateforme web gérant plusieurs organisations distinctes (multi-tenants).
Chaque organisation a des administrateurs capables d’inviter des utilisateurs et de modifier leurs paramètres. De plus, un utilisateur peut être membre de plusieurs organisations.
Un administrateur peut changer l’adresse email des utilisateurs dans son organisation. Pour accéder à une autre organisation, il suffit de modifier l’adresse email d’un utilisateur qui est membre de plusieurs organisations (comme un autre administrateur ou un utilisateur existant).
Une autre méthode consiste à inviter un utilisateur existant à rejoindre sa propre organisation, puis à modifier son adresse email une fois l’invitation acceptée. Ensuite, il reste à utiliser la fonctionnalité d’oubli de mot de passe pour obtenir l’accès au compte.
Attaques tierces
Lorsque le mot de passe de l’utilisateur n’est pas demandé lors du changement d’email, il y a un risque d’attaque de type walk-by.
En effet, si un utilisateur oublie de fermer sa session, une personne malveillante peut modifier l’adresse email du compte et obtenir un accès à distance via la fonctionnalité d’oubli de mot de passe. Néanmoins, la probabilité d’exploitation de cette attaque est très faible.
Il est également possible de rencontrer une vulnérabilité de type Cross Site Scripting (XSS), fréquente dans les applications web. Par exemple, un attaquant pourrait soumettre le formulaire de changement d’email avec sa propre adresse email comme nouvelle adresse pour l’utilisateur ciblé.
Cette vulnérabilité peut être évitée en demandant le mot de passe ou un autre secret lors du changement d’email.
Auteur : Yoan MONTOYA – Pentester @Vaadata