Top 10 de l'OWASP relatif aux risques de sécurité des API : la mauvaise gestion des actifs

En neuvième position du Top 10 des risques liés à la sécurité des API, publié par l’Open Worldwide Application Security Project® (OWASP) en 2023, on retrouve la mauvaise gestion des actifs.

Avec la multiplication des microservices et des API, la sécurité doit être intégrée dans les solutions. Cela inclut une documentation structurée et cohérente afin de garantir que les versions actuelles des API disposent de protocoles de sécurité adéquats et qu'elles soient régulièrement mises à jour.

Vecteurs d’attaque

Une mauvaise gestion des actifs des API est courante et, malheureusement, facile à exploiter par les pirates. Les anciennes versions des API ou des points de terminaison qui n'ont pas été mis à jour peuvent permettre aux pirates de bénéficier d'un accès non autorisé.

Dans de nombreux cas, ces exploits sont connus et documentés, mais le fait de ne pas appliquer les correctifs ou les mises à jour laisse les API vulnérables aux attaques.

Failles de sécurité

L'absence de gestion cohérente des actifs conduit à des systèmes non protégés. Les anciennes API peuvent également être encore actives dans les systèmes, même si elles ne sont plus utilisées. Ces systèmes devraient être supprimés, mais ils sont souvent négligés lorsque de nouveaux systèmes sont mis en place. Comme ils restent actifs, les pirates qui les repèrent peuvent souvent les utiliser comme vecteurs d'attaque.

Impacts sur les entreprises

Une mauvaise gestion des actifs peut permettre à des pirates d'accéder à des données sensibles. Il y a eu des exemples de piratage de serveurs dans leur intégralité. Des points de terminaison obsolètes dans les anciennes versions des API peuvent permettre à des pirates d'accéder à des fonctionnalités d'administration et d'élever leurs privilèges.

Comment opère une mauvaise gestion des actifs

Non seulement les exploits liés à une mauvaise gestion des actifs sont très répandus, mais ils sont également assez faciles à repérer pour les pirates. Par exemple, à moins que vous ne bloquiez l'accès aux API vulnérables par les moteurs de recherche, trouver des API exposées peut être aussi simple que d'effectuer une recherche sur Google si vous savez ce que vous cherchez. Cette pratique, connue sous le nom de Google dorking, permet d'identifier des serveurs, des routeurs et des liens de microservices.

Une fois que les pirates ont trouvé des API non protégées ou non corrigées, ils peuvent utiliser diverses méthodes pour les analyser et y accéder. Une fois introduits dans un réseau, ils utilisent des techniques de masquage et de chiffrement pour parcourir le réseau et empêcher les équipes de sécurité de les démasquer.

Exemples concrets

Plusieurs cyberattaques très médiatisées auraient pu être évitées grâce à de meilleures pratiques de gestion des actifs des API.

La faille d'Equifax, qui a conduit à l'exposition de quelque 143 millions de dossiers de consommateurs, s'est produite lorsque des pirates ont exploité une vulnérabilité connue dans un système de développement à code source ouvert. La mise à jour recommandée du logiciel Apache Struct n'ayant pas été déployée, les pirates ont pu récupérer les identifiants de la base de données et accéder à des informations sensibles, notamment des noms, des adresses, des numéros de sécurité sociale, des dates de naissance et d'autres données sur les clients. Outre l'atteinte à sa réputation, Equifax a accepté de payer 575 millions de dollars dans le cadre d'un accord avec la Federal Trade Commission (FTC).

Des failles dans l'API de Facebook ont permis à des applications tierces d'accéder aux données privées de millions d'utilisateurs sans leur consentement. Une attaque contre Twitter a permis à des applications tierces malveillantes de faire correspondre des noms d'utilisateurs et des numéros de téléphone. Chacune de ces attaques aurait pu être évitée avec une visibilité et un contrôle total de leurs API.

L'OWASP décrit un exemple dans lequel un réseau de médias sociaux a mis en œuvre une limitation du débit pour prévenir les attaques par force brute, mais l'a fait sous la forme d'un composant indépendant au lieu de l'intégrer dans le code. Si l'hôte de l'API bêta exécute la même API, la limitation de débit sera contournée, ce qui rendra possible les attaques par force brute.

Détecter les failles dans la gestion des actifs

Les outils d'analyse des API peuvent aider à découvrir des points de terminaison d'API mal configurés et non protégés.Les développeurs doivent également surveiller et consigner le trafic des API pour savoir quels points de terminaison sont sollicités et définir des alertes en cas d'accès à des points de terminaison inhabituels ou à des API qui ne sont pas publiques.

En gardant un inventaire de toutes les clés et jetons des API, vous pouvez vous assurer qu'ils soient correctement attribués afin de limiter l'accès aux seules personnes autorisées. Les clés d'API qui sont trop privilégiées peuvent présenter un risque.

Le contrôle et le suivi des versions des API sont essentiels. Un « diffing » régulier peut révéler des modifications non documentées qui ont un impact sur la sécurité. En comparant deux versions et en identifiant les différences, les développeurs peuvent s'assurer que les référentiels de code API, les fichiers de configuration et la documentation correspondent. Les développeurs peuvent alors analyser et résoudre les éventuelles divergences.

Des modifications non documentées sont parfois introduites au fil du temps et peuvent altérer les mesures de sécurité de l'API, révélant ainsi des vulnérabilités. Il est donc crucial de documenter les modifications en vue de comparaisons futures.

Prévenir les failles dans la gestion des actifs

Pour toute API, vous ne devez permettre l'accès qu'aux personnes autorisées et authentifiées comme pouvant utiliser l'API. Cela devrait également s'appliquer à la documentation des API. Les développeurs s'assurent parfois que les API sont protégées, mais laissent la documentation non protégée sur les réseaux. Une fois que les pirates ont accès à la documentation, ils peuvent souvent procéder à une rétro-ingénierie des processus pour pouvoir y accéder.

L'OWASP recommande plusieurs actions spécifiques pour limiter et prévenir les vulnérabilités liées à une mauvaise gestion des actifs, notamment :

• Documenter l'objectif, les points de terminaison, les paramètres, les demandes et les réponses pour chaque API. Pour éviter tout risque supplémentaire, précisez quelles sont les versions en cours de production et celles en cours de développement.
• Définir les services intégrés, y compris leur rôle, les flux de données et les niveaux de sécurité.
• Décrire les méthodes d'authentification, la gestion des erreurs, la limitation du débit, les politiques CORS et tout autre détail pertinent concernant la fonctionnalité de l'API.
• Automatiser la génération de la documentation en utilisant des standards ouverts et intégrer les documents dans les pipelines CI/CD.
• Mettre en œuvre une sécurité des API par niveaux pour toutes les versions, et pas seulement pour les versions en production.
• Éviter d'utiliser des données réelles pour des API qui ne sont pas en production.Le cas échéant, sécurisez-les convenablement.

Lorsque des versions plus récentes d'API renforcent la sécurité, une analyse des risques peut aider à évaluer l'impact sur d'autres versions. Par exemple, pouvez-vous rétablir les améliorations de sécurité dans les versions antérieures sans rompre la compatibilité ? Si ce n'est pas le cas, vous devrez inciter les clients à adopter la nouvelle version et supprimer l'ancienne version de l'API dès que possible.