L’application TeaOnHer déversait les données personnelles de ses utilisateurs sur le web. Ironique, non ?
TeaOnHer, cette application prétendument conçue pour permettre aux hommes de partager des photos et des informations sur les femmes avec qui ils affirment être sortis, s’est avérée être une passoire en matière de sécurité. Tout comme Tea, son homologue féminin, elle exposait les informations personnelles de ses utilisateurs, y compris des photos de leurs permis de conduire et autres pièces d’identité.
Ces applications, qui se présentent comme des espaces sécurisés pour partager des informations sur les relations amoureuses, soulignent les risques liés à la soumission d’informations sensibles.
Des risques qui s’intensifient
Avec les lois sur la vérification de l’âge, de plus en plus d’applications exigent des documents d’identité, augmentant les risques de stockage de bases de données remplies d’informations personnelles. C’est un peu comme demander à un inconnu de garder votre portefeuille… pas très rassurant !
Lorsque nous avons publié notre article la semaine dernière, nous avons délibérément omis les détails spécifiques des failles découvertes dans TeaOnHer. Notre priorité était d’éviter d’aider les personnes mal intentionnées à exploiter ces vulnérabilités.
Au moment de cette divulgation, TeaOnHer occupait la deuxième place du classement des applications gratuites sur l’App Store d’Apple, une position qu’elle conserve encore aujourd’hui.
Comment nous avons démasqué les failles de TeaOnHer
Les failles que nous avons découvertes semblent avoir été corrigées. Nous pouvons maintenant partager comment nous avons pu trouver les permis de conduire des utilisateurs en quelques minutes grâce à des failles facilement accessibles dans le système backend public de l’application, ou API.
Le développeur de l’application, Xavier Lampkin, n’a pas répondu à nos demandes de commentaires après que nous ayons soumis les détails des failles de sécurité. Il n’a pas non plus pris d’engagement à informer les utilisateurs de TeaOnHer concernés ou les autorités de réglementation de cette faille de sécurité.
Nous avons également demandé à Lampkin si des audits de sécurité avaient été effectués avant le lancement de l’application TeaOnHer, mais nous n’avons reçu aucune réponse.
Top, chrono !
TeaOnHer : Les identifiants du “panneau d’administration” exposés
Avant même de télécharger l’application, nous avons cherché à savoir où TeaOnHer était hébergée sur Internet, en examinant son infrastructure publique, comme son site web et tout ce qui était hébergé sur son domaine.
C’est souvent un bon point de départ pour comprendre à quels autres services le domaine est connecté sur Internet.
Pour trouver le nom de domaine, nous avons consulté la liste de l’application sur l’Apple App Store pour trouver le site web de l’application. On le trouve généralement dans sa politique de confidentialité, que les applications doivent inclure avant qu’Apple ne les répertorie.
La politique de confidentialité de TeaOnHer se présentait sous la forme d’un document Google publié, qui comprenait une adresse électronique avec un domaine teaonher.com, mais pas de site web.
Exploration du domaine
Comme le site web n’était pas public à ce moment-là, nous avons examiné les enregistrements DNS publics du domaine, qui peuvent aider à identifier ce qui est hébergé sur le domaine, comme le type de serveurs de messagerie ou d’hébergement web. Nous voulions également rechercher les sous-domaines publics que le développeur pourrait utiliser pour héberger des fonctionnalités pour l’application (ou héberger d’autres ressources qui ne devraient probablement pas être publiques), comme les tableaux de bord d’administration, les bases de données ou d’autres services accessibles sur le web.
Mais lorsque nous avons examiné les enregistrements Internet publics de TeaOnHer, il ne contenait aucune information significative autre qu’un seul sous-domaine, appserver.teaonher.com.
Lorsque nous avons ouvert cette page dans notre navigateur, nous avons découvert la page d’accueil de l’API de TeaOnHer. Une API permet simplement à des éléments sur Internet de communiquer entre eux, comme la liaison d’une application à sa base de données centrale.
La découverte choquante
C’est sur cette page d’accueil que nous avons trouvé l’adresse électronique et le mot de passe en clair pour le compte de Lampkin afin d’accéder au “panneau d’administration” de TeaOnHer !
La page de l’API indiquait que le panneau d’administration, utilisé pour le système de vérification des documents et la gestion des utilisateurs, était situé sur “localhost”, qui fait simplement référence à l’ordinateur physique exécutant le serveur et qui n’était peut-être pas directement accessible depuis Internet. Il n’est pas certain que quiconque ait pu utiliser les identifiants pour accéder au panneau d’administration, mais cette découverte était en soi suffisamment alarmante.
À ce stade, nous n’en étions qu’à environ deux minutes.
Sinon, la page d’accueil de l’API n’a pas fait grand-chose d’autre que de donner une indication de ce que l’API peut faire. La page énumère plusieurs points d’extrémité d’API, auxquels l’application doit accéder pour fonctionner, comme la récupération des enregistrements d’utilisateurs dans la base de données de TeaOnHer, pour que les utilisateurs puissent laisser des commentaires et envoyer des notifications.
L’API de TeaOnHer : Une mine d’informations ?
La connaissance de ces points d’extrémité permet d’interagir plus facilement avec l’API directement, comme si nous imitions l’application elle-même. Chaque API est différente, il faut donc du temps pour comprendre comment fonctionne une API et comment communiquer avec elle, comme les points d’extrémité à utiliser et les paramètres nécessaires pour parler efficacement sa langue. Des applications comme Postman peuvent être utiles pour accéder directement aux API et interagir avec elles, mais cela demande du temps, des essais et des erreurs (et de la patience) pour que les API crachent des données quand elles ne le devraient pas.
Mais dans ce cas, il existait un moyen encore plus simple.
L’API de TeaOnHer permettait un accès non authentifié aux données des utilisateurs
Cette page d’accueil de l’API comprenait un point d’extrémité appelé /docs, qui contenait la documentation auto-générée de l’API (alimentée par un produit appelé Swagger UI) qui contenait la liste complète des commandes qui peuvent être exécutées sur l’API.
Cette page de documentation était effectivement une feuille maîtresse de toutes les actions que vous pouvez effectuer sur l’API de TeaOnHer en tant qu’utilisateur régulier de l’application, et plus important encore, en tant qu’administrateur de l’application, comme la création de nouveaux utilisateurs, la vérification des documents d’identité des utilisateurs, la modération des commentaires, etc.
La documentation de l’API permettait également d’interroger l’API de TeaOnHer et de renvoyer des données d’utilisateur, ce qui nous permettait essentiellement de récupérer des données du serveur backend de l’application et de les afficher dans notre navigateur.
S’il n’est pas rare que les développeurs publient la documentation de leur API, le problème ici était que certaines requêtes API pouvaient être faites sans aucune authentification – aucun mot de passe ou identifiant n’était nécessaire pour renvoyer des informations de la base de données de TeaOnHer. En d’autres termes, vous pouviez exécuter des commandes sur l’API pour accéder aux données privées des utilisateurs qui n’auraient pas dû être accessibles à un utilisateur de l’application, et encore moins à n’importe qui sur Internet.
Tout cela était commodément et publiquement documenté pour que tout le monde puisse le voir.
Des données accessibles en un clic
Demander une liste des utilisateurs actuellement dans la file d’attente de vérification d’identité de TeaOnHer, par exemple – il suffit d’appuyer sur un bouton de la page API, rien de plus – renverrait des dizaines d’enregistrements de compte sur des personnes qui s’étaient récemment inscrites à TeaOnHer.
Les enregistrements renvoyés par le serveur de TeaOnHer contenaient les identifiants uniques des utilisateurs dans l’application (essentiellement une chaîne de lettres et de chiffres aléatoires), leur nom d’écran de profil public, et l’âge et la localisation qu’ils ont déclarés eux-mêmes, ainsi que leur adresse électronique privée. Les enregistrements comprenaient également des liens d’adresse web contenant des photos des permis de conduire des utilisateurs et des selfies correspondants.
Pire encore, ces photos de permis de conduire, de pièces d’identité délivrées par le gouvernement et de selfies étaient stockées dans un serveur cloud S3 hébergé par Amazon et accessible publiquement à toute personne ayant leur adresse web. Ce paramètre public permet à toute personne ayant un lien vers les documents d’identité d’une personne d’ouvrir les fichiers depuis n’importe où, sans restriction.
Grâce à cet identifiant unique d’utilisateur, nous pouvions également utiliser la page de l’API pour rechercher directement les enregistrements des utilisateurs individuels, ce qui renverrait les données de leur compte et tous les documents d’identité associés. Avec un accès illimité à l’API, un utilisateur mal intentionné aurait pu récupérer d’énormes quantités de données d’utilisateurs de l’application, un peu comme ce qui s’est passé avec l’application Tea pour commencer.
De la graine à la tasse, cela a pris environ 10 minutes, et nous ne nous étions même pas encore connectés à l’application. Les bogues étaient si faciles à trouver qu’il serait de la chance que personne de mal intentionné ne les trouve avant nous.
Nous avons demandé, mais Lampkin n’a pas voulu dire s’il avait la capacité technique, comme les journaux, de déterminer si quelqu’un avait utilisé (ou mal utilisé) l’API à un moment donné pour accéder aux documents de vérification des utilisateurs, par exemple en récupérant les adresses web de l’API.
Dans les jours qui ont suivi notre signalement à Lampkin, la page d’accueil de l’API a été retirée, ainsi que sa page de documentation, et elle n’affiche plus que l’état du serveur sur lequel l’API de TeaOnHer fonctionne comme “sain”. Au moins lors des tests sommaires, l’API semble désormais reposer sur l’authentification, et les appels précédents effectués à l’aide de l’API ne fonctionnent plus.
Les adresses web contenant les documents d’identité téléchargés par les utilisateurs ont également été interdites à la consultation publique.
Le développeur de TeaOnHer a rejeté les efforts de divulgation des failles
Étant donné que TeaOnHer n’avait pas de site web officiel au moment de nos découvertes, TechCrunch a contacté l’adresse électronique indiquée dans la politique de confidentialité afin de divulguer les failles de sécurité.
Mais le courriel a été renvoyé avec une erreur indiquant que l’adresse électronique n’a pas pu être trouvée. Nous avons également essayé de contacter Lampkin via l’adresse électronique sur son site web, Newville Media, mais notre courriel a été renvoyé avec le même message d’erreur.
TechCrunch a contacté Lampkin par message LinkedIn, lui demandant de fournir une adresse électronique où nous pourrions envoyer les détails des failles de sécurité. Lampkin a répondu par une adresse électronique “support” générale.
Lorsque TechCrunch divulgue une faille de sécurité, nous contactons d’abord la personne ou l’entreprise pour confirmer qu’elle est le bon destinataire. Dans le cas contraire, l’envoi aveugle des détails d’un bogue de sécurité à la mauvaise personne pourrait créer un risque. Avant de partager des détails spécifiques sur les failles, nous avons demandé au destinataire de l’adresse électronique “support” si c’était la bonne adresse pour divulguer une exposition de sécurité impliquant les données des utilisateurs de TeaOnHer.
“Vous devez nous confondre avec l’application “Tea””, a répondu Lampkin par courriel. “Nous n’avons pas de faille de sécurité ou de fuite de données”, a-t-il dit. “Nous avons tout au plus des bots, mais nous n’avons pas encore pris assez d’ampleur pour être dans cette conversation, désolé que vous ayez été mal informé”.
Satisfaits d’avoir établi le contact avec la bonne personne (bien que pas avec la réponse que nous avons reçue), TechCrunch a partagé les détails des failles de sécurité, ainsi que plusieurs liens vers des permis de conduire exposés, et une copie des propres données de Lampkin pour souligner la gravité des problèmes de sécurité.
“Merci pour cette information. C’est très préoccupant. Nous allons nous pencher sur ce problème dès maintenant”, a déclaré Lampkin.
Malgré plusieurs courriels de suivi, nous n’avons pas eu de nouvelles de Lampkin depuis que nous avons divulgué les failles de sécurité.
Que vous soyez une entreprise de logiciels composée d’une seule personne ou que vous soyez un milliardaire qui code tout un week-end, les développeurs ont toujours la responsabilité de protéger les données de leurs utilisateurs. Si vous ne pouvez pas assurer la sécurité des données privées de vos utilisateurs, ne les créez pas.
Et vous, chers lecteurs, que pensez-vous de ces pratiques ? N’hésitez pas à partager vos commentaires !
En parallèle, Alexandre nourrit une véritable passion pour le basketball, qu’il suit aussi bien sur les parquets européens que dans la NBA. Entre deux analyses macroéconomiques, il n’est jamais bien loin d’un match ou d’un débat tactique.
- Incroyable : Eric Trump prédit un Bitcoin à 987 000$ et encense le rôle de cette crypto chinoise ! Découvrez pourquoi il est si optimiste… - 31 octobre 2025
- Ce Side Hustle Crypto Affole Wall Street ! Découvrez Pourquoi 9 Spécialistes Recommandent Cette Opportunité Inattendue à 74,3% - 20 octobre 2025
- ALERTE : Ce piratage NPM inattendu aspire votre crypto ! Découvrez comment 47 packages populaires sont compromis et comment vous protéger absolument. - 6 octobre 2025