Top 10 de l'OWASP relatif aux risques de sécurité des API : édition 2023

Le projet de sécurité des API de l'OWASP réactualise son Top 10 relatif aux risques de sécurité des API pour 2023. La nouvelle liste, dont la dernière actualisation remonte à 2019, reconnaît la plupart des mêmes risques, en ajoute quelques-uns et en supprime d'autres. Par exemple, la journalisation et la surveillance, ainsi que l'injection, ne figurent plus dans ce top 10, même s'il s'agit toujours de risques majeurs. Ceux qui font leur entrée dans cette liste sont la vulnérabilité côté serveur de type SSRF et l'utilisation non sécurisée des API.

La liste n'est pas encore finalisée, mais elle est disponible sur le site Github de l'OWASP pour révision et observations. À ce jour, voici les éléments qui figurent dans la liste de 2023.

1. Défaillance de l'autorisation au niveau de l'objet
2. Défaillance de l'authentification
3. Défaillance de l'autorisation au niveau de la propriété de l'objet
4. Consommation de ressources illimitée
5. Défaillance de l'autorisation au niveau de la fonction
6. Vulnérabilité côté serveur de type SSRF
7. Configuration incorrecte de la sécurité
8. Manque de protection contre les menaces automatisées
9. Mauvaise gestion des actifs
10. Utilisation non sécurisée des API

1. Défaillance de l'autorisation au niveau de l'objet

L'autorisation au niveau de l'objet, généralement mise en œuvre au niveau du code à des fins de validation utilisateur, est une méthode de contrôle permettant de restreindre l'accès aux objets. Lorsque l'autorisation au niveau de l'objet n'est pas appliquée adéquatement, cela peut exposer les systèmes. Une telle vulnérabilité a été découverte chez Uber suite à l'envoi de demandes API incluant les numéros de téléphone des utilisateurs pour accéder aux tokens et manipuler les systèmes.

Vecteurs d'attaque : les attaques exploitent les points de terminaison des API en manipulant les identifiants d'objets envoyés dans une demande. Ce problème est malheureusement assez courant dans les applications basées sur des API, lorsque les composants côté serveur ne tiennent pas compte de toutes les données du client, mais s'appuient plutôt sur les identifiants d'objets.

Failles de sécurité : les autorisations et les contrôles d’accès sont complexes. Même avec des protocoles et des configurations appropriés, les développeurs oublient parfois de recourir à des contrôles d'autorisation avant d'accéder à des objets sensibles. Ces derniers ne sont guère compatibles avec les tests automatiques.

2. Défaillance de l'authentification

Les points de terminaison d'authentification sont vulnérables à un certain nombre de risques, notamment les attaques par force brute, le credential stuffing, les clés de chiffrement peu fiables et les connexions à d'autres microservices ne nécessitant pas d'authentification.

Vecteurs d'attaque : étant donné que ces points de terminaison peuvent être accessibles à des personnes extérieures à une entreprise, plusieurs menaces potentielles se révèlent. On peut facilement omettre de protéger une partie du périmètre d'authentification ou de mettre en œuvre les protocoles de sécurité adéquats.

Failles de sécurité : l'OWASP souligne deux problèmes spécifiques liés à l'authentification des points de terminaison :

• L'absence de mécanismes de protection comprenant des niveaux de protection supplémentaires
• La mise en œuvre inadaptée de mécanismes d'authentification ou l'utilisation d'un mécanisme inadéquat pour les applications

3. Défaillance de l'autorisation au niveau de la propriété de l'objet

Lors de l'accès à un objet via une API, les utilisateurs doivent se voir confirmer le droit d'accéder à certaines propriétés de l'objet. La défaillance de l'autorisation au niveau de la propriété de l'objet peut permettre à des utilisateurs non autorisés d'accéder à des objets et de les modifier.

Vecteurs d'attaque : les pirates exploitent les points de terminaison des API vulnérables pour lire, modifier, ajouter ou supprimer les valeurs des propriétés des objets qui ne devraient pas être accessibles aux pirates.

Failles de sécurité : quand bien même les développeurs prévoient des contrôles d'accès des utilisateurs aux fonctions et aux objets, il se peut qu'ils ne vérifient pas si les utilisateurs sont autorisés à accéder à des propriétés spécifiques aux objets.

4. Consommation de ressources illimitée

Sans restrictions sur les demandes d'API, les pirates qui envoient des demandes multiples ou qui inondent les ressources peuvent mettre en œuvre des attaques par déni de service (DoS) et causer des dommages financiers à ceux qui ont recours à la facturation à la demande. Les attaques par déni de service distribué (DDoS) ont considérablement augmenté au cours des deux dernières années, jusqu'à 60 %.

Vecteurs d'attaque : les API peuvent être exploitées en envoyant plusieurs demandes simultanées à des API qui ne limitent pas les interactions.

Failles de sécurité : souvent, les API ne limitent pas les activités telles que les délais d'exécution, la mémoire maximale autorisée, le nombre d'opérations des demandes des clients ou l'application de plafonds de dépenses pour les tiers. Même avec la journalisation, il est facile pour une activité malveillante de passer inaperçue au début.

5. Défaillance de l'autorisation au niveau de la fonction

Lorsque l'autorisation au niveau de la fonction permet aux utilisateurs d'accéder aux points de terminaison administratifs, ils peuvent effectuer des actions à caractère sensible.

Vecteurs d’attaque : les pirates peuvent repérer les failles des API parce qu'elles sont plus structurées et prévisibles dans la méthodologie d'accès, et ils peuvent alors envoyer des appels API légitimes à des points de terminaison auxquels ils ne devraient pas être en mesure d'accéder. Dans certains cas, il suffit de deviner l'URL du point de terminaison et de remplacer « users » par « admins » dans les chaînes.

Failles de sécurité : les applications modernes intègrent un grand nombre de rôles, de groupes et de hiérarchies d'utilisateurs complexes. Les utilisateurs peuvent avoir des rôles différents pour des domaines ou des objets différents, ce qui peut compliquer les contrôles.

6. Vulnérabilité côté serveur de type SSRF

La vulnérabilité côté serveur de type SSRF peut se produire lorsqu’une API récupère une ressource distante sans valider au préalable l’URL fournie par les utilisateurs. Les serveurs peuvent être utilisés comme proxy pour dissimuler des activités malveillantes. Des chercheurs ont récemment découvert quatre cas de vulnérabilités SSRF dans la gestion de l'API Azure, qui ont depuis été corrigées.

Vecteurs d'attaque : les pirates trouvent un point de terminaison API qui reçoit un identifiant de ressource universel (URI) et forcent l'application à envoyer une demande vers une destination inattendue, même lorsque les destinations sont protégées par un firewall ou un VPN.

Failles de sécurité : le développement d'applications comprend souvent l'accès à des URI fournis par le client, et la récupération de données côté serveur n'est généralement pas journalisée ou surveillée.

7. Configuration incorrecte de la sécurité

Renforcer la sécurité de la pile d'API devrait être une priorité absolue pour les développeurs, mais les autorisations sont souvent appliquées de manière inadéquate ou incohérente dans les services cloud. Dans d'autres cas, les correctifs de sécurité et les logiciels sont obsolètes. Il y a eu plusieurs cas très médiatisés où des entreprises n'ont pas protégé correctement leurs ressources cloud, comme le United States Army Intelligence and Security Command, et dans ce cas, les données non protégées comprenaient des fichiers classés top secret.

Vecteurs d'attaque : les pirates recherchent activement des failles non corrigées et des fichiers ou répertoires non protégés, et s'attaquent aux points de terminaison les plus courants afin de cartographier les systèmes et d'obtenir un accès non autorisé. Les divergences dans la manière dont les demandes sont traitées favorisent la prolifération des vecteurs d'attaque.

Failles de sécurité : des erreurs de configuration peuvent survenir à tous les niveaux, du réseau à l'application. Les options obsolètes et les services inutiles peuvent également favoriser l'apparition de vecteurs d'attaque.

8. Manque de protection contre les menaces automatisées

Les cybercriminels et autres pirates redoublent d'ingéniosité dans leurs tactiques et les API sont des cibles de choix. L'automatisation est bon marché et largement disponible sur le dark web. Les API elles-mêmes peuvent ne pas présenter de défauts ou de bugs, mais le flux d'activité sous-jacent peut être vulnérable à une activité abusive.

Vecteurs d'attaque : les pirates se familiarisent avec les modèles d'API et les flux commerciaux, puis les exploitent à l'aide d'outils automatisés. Par exemple, l'utilisation d'outils automatisés et de botnets peut contourner la limitation du débit en répartissant les requêtes sur des adresses IP.

Failles de sécurité : la difficulté réside dans le fait que chaque demande peut sembler légitime, de sorte qu'elle ne sera pas identifiée comme une attaque. Cependant, ces attaques automatisées peuvent inonder les systèmes et empêcher les utilisateurs légitimes d'y accéder.

9. Mauvaise gestion des actifs

Les API des applications peuvent être très complexes et interconnectées. La connectivité avec des tiers augmente l'exposition aux menaces, et il arrive souvent que de multiples versions d'API non gérées soient exploitées. Les documents obsolètes ou manquants peuvent rendre difficile le suivi de tous les éléments.

Vecteurs d'attaque : les pirates peuvent accéder à d'anciennes versions d'API ou à des points de terminaison non corrigés. Ils peuvent également y accéder par l'intermédiaire de tiers.

Failles de sécurité : l'absence de gestion des stocks ou des actifs peut entraîner toute une série de problèmes, notamment des systèmes non corrigés. Les hôtes API peuvent être exposés par le biais de microservices, qui assurent l'indépendance des applications dans de nombreux cas. L'absence de méthode systématique et étayée visant à déployer, gérer et retirer les API peut conduire à différentes failles de sécurité.

10. Utilisation non sécurisée des API

Lorsque vous travaillez avec des tiers et des fournisseurs connus, vous pouvez généralement vous fier aux données que vous recevez et il se peut que les normes de sécurité soient moins strictes. Cependant, si les pirates peuvent pirater des tiers, ils pourraient être en mesure de causer des dommages par l'intermédiaire des API qui vous relient. Aujourd'hui, près de la moitié des violations de données sont dues à des connexions impliquant des tiers.

Vecteurs d'attaque : l'exploitation des failles de sécurité des API se produit lorsque les développeurs font confiance aux points de terminaison qui interagissent avec les API, mais ne les vérifient pas et ne les protègent pas pleinement. Par exemple, ils peuvent ne pas imposer de limites appropriées aux ressources, ne pas approuver les redirections ou ne pas approuver ni analyser les demandes de données provenant des API avant de les traiter.

Failles de sécurité : les failles de sécurité apparaissent souvent lorsque des modèles de sécurité plus faibles sont appliqués aux intégrations d'API, en particulier dans des domaines tels que la sécurité du transport, la validation des saisies, la validation des données, l'authentification et l'autorisation. Cela expose les entreprises à des accès non autorisés et à des intrusions malveillantes.

L'OWASP accepte les commentaires et les retours

Le Top 10 de l'OWASP relatif aux risques de sécurité des API est conçu pour aider les entreprises à se familiariser avec les principaux risques et menaces associés à leurs API et à apporter des solutions pour renforcer la sécurité.

L'OWASP sollicite actuellement des contributions et des retours concernant cette liste avant sa publication finale. Vous pouvez consulter la liste et faire part de vos commentaires via le gestionnaire de problèmes sur le site Github.