Série Coders Conquer Security OWASP Top 10 API - Mauvaise gestion des actifs

Contrairement à la plupart des vulnérabilités du Top 10 API de l'OWASP, une mauvaise gestion des actifs ne concerne pas spécifiquement des failles de codage. Il s'agit plutôt d'un problème humain ou organisationnel qui permet à d'anciennes API de rester actives bien après avoir dû être remplacées par des versions plus récentes et sécurisées. Cela peut également se produire si des API encore en développement sont exposées dans l'environnement de production avant d'être totalement protégées contre les menaces.

Cette vulnérabilité est particulièrement difficile à gérer en raison de l'avènement des microservices et du cloud computing. Dans cet environnement, de nouveaux services peuvent être déployés rapidement pour répondre à un besoin temporaire, puis oubliés et jamais mis hors service. Si ces anciennes API restent connectées à l'environnement de production, elles peuvent mettre en péril l'ensemble du réseau.

Envie de vous essayer à un défi ludique sur cette faille de sécurité ? Entrez dans notre arène : [Commencer ici]

Comment les failles de gestion des actifs affectent-elles les API ?

La faille liée à une mauvaise gestion des actifs est un produit de notre époque. Les organisations, évoluant au rythme du marché, peuvent parfois lancer des centaines, voire des milliers de services et microservices chaque jour. Cela se fait souvent rapidement, sans documentation associée ni explication sur l'usage, la durée de vie ou la criticité de ces API. Cela peut générer une prolifération incontrôlable d'API, surtout en l'absence de politiques globales définissant leur durée de vie.

Dans un tel environnement, il est fort probable que certaines API soient perdues, oubliées ou jamais mises hors service.

Les utilisateurs autorisés à créer de nouveaux services en dehors du processus standard sont parfois en cause. Par exemple, une équipe marketing peut créer un service pour un événement ponctuel, comme un lancement de produit, et oublier de le supprimer une fois l'événement terminé. Quiconque examinera ce service plus tard pourrait ignorer sa raison d'être. En l'absence de documentation, il peut rester un mystère. Par crainte, les équipes pourraient hésiter à supprimer ou mettre à jour ces API, ignorant leur criticité ou leur fonction réelle.

Cette vulnérabilité est dangereuse car la sécurité des frameworks API s'améliore avec le temps. Un chercheur peut découvrir une faille, ou des mesures de sécurité supplémentaires peuvent être ajoutées pour contrer des attaques populaires. Les anciennes API restent vulnérables à ces attaques si elles ne sont pas mises à jour, ce qui incite les pirates à les rechercher activement, souvent à l'aide d'outils automatisés.

Dans un exemple concret fourni par l'OWASP, une entreprise a mis à jour ses API de recherche dans des bases de données utilisateurs pour corriger une faille critique, mais a oublié de supprimer les anciennes API.

Un attaquant a remarqué que l'emplacement de la nouvelle API était (api.criticalservice.com/v2). En remplaçant l'URL par (api.criticalservice.com/v1), il a pu utiliser l'ancienne API vulnérable. Cela a finalement exposé les dossiers personnels de plus de 100 millions d'utilisateurs.

Éliminer les failles de gestion des actifs

La seule façon d'éliminer ce risque est de maintenir un inventaire rigoureux de toutes les API, de leurs usages et de leurs versions. Cela commence par l'inventaire des API existantes, en se concentrant sur des facteurs tels que l'environnement de déploiement (production ou développement), les accès réseau requis et, bien entendu, la version.

Une fois cette étape terminée, vous devez mettre en place un processus d'ajout automatique de documentation pour toute nouvelle API ou tout nouveau service. Cela doit inclure tous les aspects de l'API : limitation de débit, gestion des requêtes et réponses, partage de ressources, points de terminaison autorisés, politiques applicables et toute information nécessaire à un audit futur. Évitez d'utiliser des API de développement en production. Envisagez également d'ajouter une limite de temps aux API, dont le maintien devra être justifié par leurs propriétaires pour éviter toute mise hors service automatique.

Dès qu'une nouvelle version d'une API active est disponible, effectuez une évaluation des risques pour déterminer si une mise à jour est nécessaire et comment l'effectuer sans perturber la production. Une fois la migration vers les nouvelles API terminée, supprimez définitivement les anciennes.

Ces mesures aideront à protéger votre organisation, vos utilisateurs et votre réseau contre les risques liés à une mauvaise gestion des actifs. Consultez le blog de Secure Code Warrior pour plus d'informations sur cette vulnérabilité et sur la manière de protéger votre entreprise. Vous pouvez également essayer une démo de la plateforme de formation Secure Code Warrior pour maintenir vos compétences en cybersécurité à jour.

‍