Cette semaine, nous avons des nouvelles sur une brèche affectant 400 000 utilisateurs d’une application scolaire allemande populaire, et une autre vulnérabilité dans un plugin WordPress populaire. En outre, il existe un article d’opinion stimulant sur la valeur de GraphQL sur les interfaces publiques et un article présentant neuf outils de test d’API utiles.
Violation : les données sensibles de 400 000 étudiants allemands exposées à la faille de l’API
La semaine dernière, la nouvelle d’une brèche dans une application populaire de la communauté étudiante allemande, Scoolio, a été découverte par la chercheuse en sécurité Lilith Wittmann. Des estimations prudentes évaluent le nombre d’étudiants concernés à 400 000 étudiants, mais la façon dont Scoolio crée des comptes d’utilisateurs jette une certaine incertitude sur le chiffre exact ici.
Wittman décrit (en allemand) comment elle a pu exploiter l’API Scoolio pour récupérer des données utilisateur sensibles, telles que :
- Pseudos d’utilisateurs
- Adresses e-mail des utilisateurs et des parents
- Localisation GPS de la dernière utilisation de l’application
- Nom de l’école et de la classe
- Traits de personnalité comme l’origine, la religion, la sexualité
Vous trouverez ci-dessous un exemple du type d’informations utilisateur divulguées :
Il a fallu un peu plus d’un mois aux développeurs de Scoolio pour déployer un correctif au problème, mais ils ont eu la gentillesse de remercier publiquement Wittman pour sa divulgation responsable.
La nature précise de la vulnérabilité n’a pas été divulguée, mais il semblerait qu’il s’agisse d’un exemple d’API1:2019 – Autorisation brisée au niveau de l’objet, basée sur les UUID des comptes.
Vulnérabilité : le plugin WordPress OptinMonster affecte 1 million de sites
Une autre semaine, une autre vulnérabilité affectant les utilisateurs de WordPress, cette fois dans un plugin marketing populaire appelé OptinMonster. La vulnérabilité est similaire aux vulnérabilités de plugin précédentes que nous avons vues : les points de terminaison d’API exposés par le plugin n’étaient pas correctement sécurisés, permettant à un attaquant de compromettre le déploiement.
La vulnérabilité a été découverte par l’équipe de Wordfence, qui s’est rapidement mobilisée pour protéger leurs clients concernés, et a conseillé OptinMonster, qui a répondu tout aussi rapidement et a corrigé le problème dans la version 2.6.5 du plugin.
Il s’est avéré que de nombreux points de terminaison de l’API REST n’étaient pas implémentés de manière sécurisée, ce qui permettait aux attaquants de multiples voies d’accéder à une installation affectée. Le plus grave était le point final /wp-json/omapp/v1/support qui a en fait divulgué une clé API utilisée pour faire des demandes au site Web OptinMonster. Un attaquant pourrait facilement utiliser cette clé API pour apporter des modifications à toutes les campagnes qui lui sont associées, y compris potentiellement intégrer du code JavaScript dangereux.
Comme nous l’avons vu avec des vulnérabilités de plugin similaires dans WordPress, cela a tendance à provenir de la façon dont le permissions_callback méthode est mise en œuvre. Le noyau WordPress déclenche ce rappel pour permettre au plugin de valider la requête API, généralement en effectuant des vérifications sur l’authentification et l’autorisation de l’appelant. Malheureusement, la mise en œuvre dans le cas OptinMonster laissait beaucoup à désirer, car il n’y avait aucune tentative de vérifier les autorisations de l’appelant. Il suffisait que l’appelant soit connecté et dispose d’une clé API valide ! Un bon exemple d’API5:2019 – Autorisation de niveau de fonction cassée.
La clé à retenir ici est que les développeurs d’API s’assurent que tous les appelants d’API sont pleinement autorisés pour les points de terminaison d’API appelés.
Opinion: GraphQL n’est pas destiné à être exposé sur Internet
Auparavant, nous avons présenté le point de vue de Jens Neuse sur le renforcement et la sécurisation des implémentations GraphQL. Cette semaine, il revient sur GraphQL dans un article provocateur qui suggère que GraphQL ne devrait pas être exposé sur Internet !
Selon Neuse, dans de nombreux cas, GraphQL est une indulgence inutile qui n’est pas requise d’un point de vue technique et ajoute à l’exposition au risque. En règle générale, les avantages de GraphQL ne se manifestent que pour les soi-disant « licornes » comme Facebook et GitHub. Le conseil de Neuse est de déterminer si vous avez vraiment besoin de GraphQL.
Neuse recommande qu’un examen de sécurité des risques soit effectué si GraphQL est utilisé, en accordant une attention particulière aux éléments suivants :
- Dans quelle mesure les bibliothèques sur lesquelles votre point de terminaison est construit sont-elles sécurisées ?
- Comprenez-vous comment ils fonctionnent et quelles limites ils peuvent avoir ?
- Exposez-vous par inadvertance votre API même si vous désactivez le terrain de jeu visuel GraphQL ?
- Activez-vous la requête d’introspection qui pourrait divulguer des informations sensibles telles que le schéma de données sous-jacent ?
- Connaissez-vous les attaques par traversée de schéma ?
Quiconque envisage une implémentation de GraphQL ferait bien de lire et de comprendre cet article, ainsi que sa préquelle. Comme Neuse conclut avec la langue fermement dans la joue:
« Si vous voulez être sûr à 100 %, vous devriez envisager de débrancher le câble réseau. Cependant, cela présente des inconvénients gênants.
Guide : neuf outils de test d’API en ligne
Enfin, cette semaine, une lecture rapide d’Idowu Omisola sur neuf outils de test d’API en ligne.
L’article couvre certains des outils standard de l’industrie, tels que Postman et Swagger Inspector, mais présente également des outils moins connus comme l’excellent Paw pour les utilisateurs de MacOS et le Fiddler Everywhere mis à jour de Telerik.
Dans l’ensemble, un guide utile pour tout testeur d’API ou pirate informatique.
Vous pouvez vous inscrire à cette newsletter sur APIsecurity.io.