Ce n'est pas toujours logique
Encore une violation d'API dans l'actualité. La dernière s'est produite sur la plateforme Life360, où un attaquant a pu collecter 400 000 numéros de téléphone d'utilisateurs, selon l'article publié sur Bleepingcomputer.com.
Connu uniquement sous son pseudonyme « emo », il a déclaré que le point d'accès API non sécurisé utilisé pour voler les données offrait un moyen facile de vérifier l'adresse e-mail, le nom et le numéro de téléphone de chaque utilisateur concerné.
« Lors d'une tentative de connexion à un compte Life360 sur Android, le point d'accès de connexion renvoyait le prénom et le numéro de téléphone de l'utilisateur ; ces informations n'existaient que dans la réponse de l'API et n'étaient pas visibles par l'utilisateur », a déclaré emo.
« Si un utilisateur avait vérifié son numéro de téléphone, il serait alors renvoyé sous forme de numéro partiel comme +1******4830. »
En d'autres termes, l'attaquant a pu tirer parti du fait que l'API fournissait trop d'informations. Je suis sûr que l'équipe de développement Android n'a jamais imaginé que quelqu'un utiliserait un émulateur ou un proxy pour examiner le trafic réel renvoyé par l'API. Au lieu de cela, ils ont pensé qu'en n'affichant pas ces informations dans l'application, même si elles étaient présentes dans l'API, ils seraient en sécurité. La sécurité par l'obscurcissement n'est pas une bonne sécurité. Cela serait classé comme une attaque OWASP API Top 10, n°3 : « Exposition excessive de données ».
Des violations comme celle-ci se produisent plus souvent que nous ne voulons l'admettre. Souvent, les applications mobiles exploitent les limitations de leur environnement pour masquer des données au lieu d'empêcher leur divulgation dès le départ. Dans un cas très similaire, une application appelée 3Fun (en savoir plus sur 3Fun) a exposé la localisation et les photos privées de ses utilisateurs via son API, bien que l'application mobile n'affichait pas ces informations.
Détection Salt
Dans cette situation spécifique, j'ai demandé à notre VP de la recherche en sécurité, Yaniv Balmas, ce que Salt aurait pu détecter.
Yaniv a déclaré que Salt aurait pu détecter plusieurs types d'opportunités, mais les plus pertinentes auraient probablement été l'énumération de paramètres (spécifiquement l'énumération qui renvoie également des données sensibles). Il a également déclaré que, puisque Salt aurait considéré cela comme une activité unique pour cet attaquant, s'écartant du comportement normal de l'utilisateur, cela aurait déclenché une alerte BOLA à identifiant unique.
La capacité de Salt à détecter et corréler ce type d'activité n'est pas chose facile. C'est comme chercher une aiguille dans une pile d'aiguilles, elle-même perdue dans une meule de foin au milieu d'une grange pleine de foin. Notre architecture unique et nos modules de détection brevetés sont la raison pour laquelle nous aidons certaines des plus grandes entreprises à protéger leurs API.
Si vous souhaitez en savoir plus sur Salt et comment nous pouvons vous aider en matière de découverte, de gouvernance et de protection des API, veuillez nous contacter, planifier une démo, ou consultez notre site web.