Top 10 de l’OWASP relatif aux risques de sécurité des API : défaillance de l’autorisation au niveau des fonctions

La défaillance de l'autorisation au niveau de la fonction figure en cinquième position sur la liste des 10 principaux risques de sécurité des API établie par l'Open Worldwide Application Security Project® (OWASP).

Une défaillance de l’autorisation au niveau de la fonction (BFLA) se produit lorsque des points de terminaison sont accessibles à des utilisateurs non autorisés.

Vecteurs d'attaque

Les pirates envoient des appels d'API légitimes à un point de terminaison auquel ils ne devraient pas pouvoir accéder. Ces appels peuvent provenir d’utilisateurs anonymes ou d’utilisateurs habituels qui ne devraient pas jouir de certains accès réservés.

Lorsque les points de terminaison sont vulnérables, les pirates n’ont aucun mal à les exploiter. Les appels d’API étant généralement structurés, les pirates peuvent apporter de petites modifications aux chaînes de caractères de manière prévisible. Cette attaque est similaire aux exploits BOLA (Défaillance de l’autorisation au niveau de l’objet), mais dans ce cas, les pirates se concentrent sur les fonctions de l’API au lieu de ses objets. Souvent, les deux types d’attaques sont utilisés conjointement pour déjouer la sécurité.

Failles de sécurité

Une autorisation mal appliquée ou mal configurée peut entraîner des failles de sécurité. Cette situation est étonnamment fréquente, car les points de terminaison des API font souvent partie d’une infrastructure complexe et comptent un grand nombre d’utilisateurs, de groupes et de rôles, y compris des utilisateurs ayant des rôles multiples. Les conceptions et les architectures de distribution de type cloud-native peuvent rendre cette gestion particulièrement complexe.

Ces failles sont généralement faciles à détecter en procédant à une évaluation minutieuse des privilèges d’accès, mais cela peut s’avérer délicat en raison du nombre considérable d’utilisateurs et de privilèges au sein des applications.

Impacts sur les entreprises

Lorsque des pirates ont un accès illimité aux fonctionnalités de l’API, les conséquences pour l’entreprise peuvent être lourdes. Cela peut entraîner l’exposition de données sensibles, la corruption ou la perte de données, ou encore l’interruption des services. Par exemple, les pirates peuvent être en mesure d’accéder à des comptes d’utilisateurs, de créer ou de supprimer des comptes ou des données, de pirater des comptes ou d’élever des privilèges.

Fonctionnement de la défaillance de l'autorisation au niveau de la fonction

L’autorisation au niveau de la fonction permet un contrôle granulaire de fonctions spécifiques au sein d’une application. En l’absence de contrôles d’accès appropriés au niveau de la fonction, les données peuvent être exposées. Cela peut survenir de plusieurs façons, par exemple :

• Paramètres incorrects au niveau du contrôle d'accès basé sur les rôles (RBAC)
• Erreurs de codage, configurations incorrectes ou manque de contrôles d’autorisation au niveau des fonctions
• Des modèles trop prévisibles, tels que les identifiants séquentiels, ou des modèles faciles à identifier
• Exposition de détails de mise en œuvre ou de configuration, comme des clés ou des identifiants de base de données

Le plus souvent, ces exploits se produisent parce que les points de terminaison de l’API sont configurés pour authentifier les utilisateurs lors de la connexion, mais une fois la session établie, les points de terminaison ne vérifient pas que les utilisateurs disposent de l’autorisation d’exécuter certaines commandes.

Exemples concrets

Deux exemples concrets d’exploits BFLA datant de 2022 illustrent à quel point cette pratique peut s’avérer préjudiciable.

Des informations personnelles concernant des résidents du Texas, issues de près de deux millions de demandes d’indemnisation, ont été divulguées. L’API du Texas Department of Insurance (DPI) permettait d’accéder à des fonctions de l’application qui auraient dû être protégées. La faille est passée inaperçue pendant près de trois ans et a été découverte lors d’un audit de gestion des données.

Près de 10 millions de dossiers client ont été compromis lors d’un exploit d’autorisation au niveau de la fonction dirigé sur Optus, la deuxième plus grande entreprise de télécommunications d’Australie, fin 2022. Les données ont été exfiltrées, et l’entreprise a reçu des demandes de rançon pour ne pas être exposée.

Détection des vulnérabilités de défaillance de l'autorisation au niveau des fonctions

Il existe plusieurs approches pour détecter les défaillances des autorisations au niveau des fonctions, notamment les analyses de code manuelles axées sur les contrôles d’accès à l’API. Les autres méthodes sont les suivantes :

• Tests de pénétration (manuels ou automatisés) pour simuler des attaques réelles afin de déceler les vulnérabilités au niveau des fonctions
• Les fuzz tests, qui consistent à tester les points d’extrémité de l’API en utilisant des entrées inattendues ou non valides, ou des utilisateurs non autorisés
• Révision des rôles et des privilèges des utilisateurs au niveau de la fonction

Prévention des vulnérabilités de défaillance de l'autorisation au niveau des fonctions

Pour empêcher une BFLA, il faut déployer des contrôles d’autorisation appropriés. Par exemple, un utilisateur lambda peut-il accéder à un point de terminaison administratif ?

Les stratégies spécifiques comprennent :

Validation au niveau des fonctions

Les utilisateurs doivent être soumis à des contrôles d’autorisation pour chaque fonction, et pas seulement au niveau de l’application. Chaque opération doit faire l’objet d’une autorisation, afin d’empêcher les utilisateurs non autorisés d’accéder aux fonctions de l’API.

Accès réseau zero trust (ZTNA)

Dans l’ensemble de l’infrastructure, les entreprises doivent appliquer des pratiques « Zero Trust ». Même les utilisateurs autorisés doivent faire l’objet d’une vérification pour chaque action, de sorte que même si les utilisateurs ont pénétré le périmètre de sécurité, ils doivent toujours être autorisés au niveau de la fonction.

Zero Trust intègre également le principe du moindre privilège (PoLP), qui consiste à accorder aux utilisateurs le niveau d’accès et de privilèges minimal dont ils ont besoin pour accomplir les fonctions autorisées.

Gestion sécurisée des sessions

L’utilisation de jetons de session sécurisés, de délais d’expiration et la révocation des jetons lors de la déconnexion peuvent également contribuer à limiter l’accès non autorisé aux fonctions de l’API.

Surveillance continue

En comparant l’activité de référence à l’activité actuelle, le système de surveillance peut rechercher des anomalies susceptibles d’indiquer une activité suspecte et bloquer l’accès ou le signaler afin qu’il soit contrôlé. Par exemple, les appels rapides d’API pour des identifiants séquentiels peuvent générer des alertes.

Gérer tous les accès administratifs

Tous les contrôleurs administratifs doivent faire l’objet de contrôles d’autorisation distincts en fonction du groupe et du rôle de l’utilisateur. Il est également important de séparer les privilèges administratifs des fonctions générales de l’API, en empêchant l’accès au niveau administrateur sans autorisation appropriée.

Audits de sécurité réguliers

Comme pour d’autres exploits potentiels liés aux API, des audits et des tests de sécurité réguliers peuvent garantir la présence de contrôles de sécurité et d’accès fiables pour empêcher tout accès non autorisé aux points d’extrémité et aux fonctionnalités des API.