Voici la deuxième occurrence de notre série d'articles abordant la sécurité dans le développement Web moderne. Toutes les deux semaines, nous investiguons une vulnérabilité qui a fait les actualités et nous vous présentons les détails de cette attaque et les apprentissages que l'on peut en faire.
Image modifiée produite par Alcoba sous licence CC-BY 2.0
En Janvier, pendant un audit de sécurité de routine à Facebook, un employé à trouvé que plusieurs millions de mots de passes étaient stockés en clair (donc complètement visibles) dans les outils internes de Facebook. La plupart des utilisateurs affectés étaient des utilisateurs de Facebook Lite, l’application Facebook Android minimaliste. D’après Facebook, aucun employé n’a utilisé ces informations et les utilisateurs impactés ont été informés.
Facebook affirme que l’impact est minimal car ces données n’ont pas été récupérées, ni par des acteurs extérieurs, ni par les employés. Cependant l’impact aurait pu être beaucoup plus grand ! Une deuxième faille de type « path traversal », aurait permis à un pirate de récupérer ces fichiers et donc de récupérer tous les mots de passe en question. Un employé malveillant aurait aussi pu s’en servir à mauvais escient.
C’est un problème grave, parce que les mots de passe peuvent non seulement être utilisés pour accéder au compte Facebook de l’utilisateur, mais également parce que beaucoup de personnes utilisent un même mot de passe pour plusieurs comptes différents. 😥 Étant des données extrêmement sensibles, les mots de passe devraient être chiffrés en transit (entre la saisie par l’utilisateur et l’arrivée sur le serveur), et au repos (dans la base de données). Facebook n’a pas communiqué sur les causes de ce problème. On peut cependant émettre plusieurs hypothèses :
- 🤦♂️ Les mots de passe étaient stockés en clair dans la base de données, ou dans des sauvegardes. C’est cependant peu probable car le hachage des mots de passe est une pratique extrêmement courante. Et d’après Facebook, les mots de passes stockés dans la base de données sont effectivement chiffrés de manières irréversible avec scrypt.
- 🤦♂️ L’application Android de Facebook logue les interactions de l’utilisateur, et le mot de passe en fait partie. Ces logs se retrouvent sur à terme sur les serveurs de Facebook. Ici aussi, c’est improbable, parce que récupérer ce que saisit l’utilisateur serait un viol de la vie privée des utilisateurs. (Cela dit je rappelle qu’on parle de Facebook. 😝)
- 🤦♂️ Les mots de passe sont, à un moment ou à un autre, présents en tant que queryParams dans une URL (cela veut dire que certaines URLs ressemblent à https://facebook.com/une-url-parmi-d-autres?password=ilovelean). Et le mot de passe se retrouve dans les logs d’accès, ou dans des analytics.
- 🤦♂️ Les mots de passe sont présents dans le body des routes POST (c’est ce qui se passe par défaut quand on fait des formulaires). Les développeurs ont logué les paramètres de ces requêtes pour pouvoir débugger plus facilement, sans se poser la question de la criticité des données.
- 🤦♂️ Les mots de passe sont présents dans le body des routes POST et sont loggués automatiquement par une des briques sur le chemin entre le navigateur et le serveur.
Pour que ce problème n’arrive pas sur vos applications et sur vos projets, plusieurs bonnes pratiques sont à mettre en place :
- 🛡 Chiffrer vos échanges entre votre site ou application et vos serveurs en HTTPS.
- 🛡 Stocker les mots de passe dans la base de données avec un algorithme de hachage.
- 🛡 Ne jamais mettre de données sensibles (mots de passe, jetons d’authentification, cookie, dans les paramètres d’une URL).
- 🛡 Ne pas loguer d’informations susceptibles d’êtres confidentielles. Le plus souvent, les métadonnées d’une action (date, URL, IP d’utilisateur, message d’erreur) sont suffisantes.
Vous avez aimé cette newsletter ? Inscrivez-vous avec votre e-mail pour ne pas rater les prochaines.
Nous avons pour ambition de sécuriser le Web, et pour atteindre cet objectif, nous avons besoin de vous ! Si vous avez des questions, des suggestions ou le moindre doute n'hésitez pas à contacter l'équipe sécurité, directement ou par mail (security@theodo.fr).
