Les failles d'autorisation sont souvent le résultat d'une autorisation mal implémentée ou mal configurée. La mise en œuvre de mécanismes d'autorisation adéquats est une tâche complexe, car les applications modernes peuvent contenir de nombreux types de rôles, de groupes et de hiérarchies d'utilisateurs, tels que des sous-utilisateurs et des utilisateurs ayant plusieurs rôles. Ceci est encore compliqué par les architectures d'applications distribuées et la conception cloud-native. L'autorisation au niveau des fonctions défaillante (BFLA) présente des similitudes avec l'autorisation au niveau des objets défaillante (BOLA) à cet égard.
Les attaquants peuvent découvrir ces failles dans les API car les appels d'API sont structurés et prévisibles, même dans les conceptions REST. Cela peut être fait en l'absence de documentation d'API ou de définitions de schéma en effectuant de l'ingénierie inverse sur le code côté client et en interceptant le trafic applicatif. Certains points d'accès API peuvent également être exposés à des utilisateurs réguliers, non privilégiés, ce qui les rend plus faciles à découvrir pour les attaquants.
Ces failles peuvent être exploitées en envoyant des requêtes API légitimes à un point d'accès API auquel les attaquants ne devraient pas avoir accès ou en interceptant et en manipulant des requêtes API provenant d'applications clientes. Par exemple, un attaquant pourrait changer une méthode HTTP de GET à PUT. Alternativement, l'attaquant pourrait également modifier un paramètre de requête ou une variable du corps du message, comme changer la chaîne « users » en « admins » dans une requête API.
Quelle est la différence entre BOLA et BFLA ?
L'autorisation au niveau des fonctions défaillante (BFLA) peut être considérée comme une version de niveau supérieur de l'autorisation au niveau des objets défaillante (BOLA). La principale différence est que, lors de l'exploitation d'une vulnérabilité BFLA, un attaquant se concentre sur les fonctions API générales plutôt que sur les objets API individuels. La conséquence de la BFLA est que les clients peuvent accéder à des fonctionnalités au-delà de leur niveau d'accès prévu, telles que des fonctions administratives.
Les attaquants tenteront d'exploiter les deux vulnérabilités lorsqu'ils ciblent des API afin d'escalader les privilèges horizontalement ou verticalement.
Impact potentiel d'une attaque par autorisation au niveau des fonctions défaillante
L'autorisation au niveau des fonctions défaillante (BFLA) a été identifiée comme la cinquième menace la plus critique pour les API dans le Top 10 de la sécurité des API de l'OWASP, et ce, à juste titre. En fait, les attaquants exploitant les vulnérabilités d'autorisation au niveau des fonctions défaillante peuvent obtenir l'accès à des ressources non autorisées, prendre le contrôle du compte d'un autre utilisateur, créer/supprimer des comptes, ou escalader les privilèges pour obtenir un accès administratif.
Téléchargez dès aujourd'hui l'eBook Top 10 de la sécurité des API de l'OWASP
À quoi ressemble une attaque BFLA ?
Exemple concret : New Relic Synthetics
En 2018, le cyber-chercheur Jon Bottarini a découvert qu'un utilisateur restreint pouvait apporter des modifications aux alertes sur New Relic Synthetics moniteurs sans les autorisations appropriées pour le faire. En fait, ils pouvaient apporter des modifications sans aucune autorisation en raison de la faiblesse d'escalade de privilèges présente dans le produit à ce moment-là. L'exploitation impliquait la soumission d'une requête légitime à un point de terminaison d'API qui n'était autrement pas visible pour l'utilisateur restreint.
Dans le cadre de ses recherches en sécurité, Bottarini a capturé le trafic d'une session privilégiée à l'aide d'un outil de proxy intercepteur, Portswigger Burp Suite. Ce trafic comprenait une requête POST vers un point de terminaison d'API et une fonction qui crée des alertes sur les moniteurs Synthetics. Il a découvert qu'il était possible d'intercepter une requête GET d'une session non privilégiée, de conserver les jetons et les cookies de cet utilisateur restreint, et de modifier le reste de la requête interceptée pour qu'elle ressemble à la requête POST privilégiée. Cette manipulation du trafic API pour accéder à des fonctionnalités non visibles dans l'interface utilisateur (du tout ou pour cet utilisateur et ses autorisations) est une technique courante utilisée par les attaquants pour exploiter les faiblesses d'autorisation au niveau des fonctions et escalader les privilèges.
Pourquoi les outils existants ne parviennent pas à protéger vos API contre les BFLA
Les contrôles de sécurité traditionnels comme les WAF et les passerelles API manquent de contexte sur l'activité API et ne savent donc pas que l'attaquant du premier exemple ci-dessus ne devrait pas être en mesure d'envoyer une méthode DELETE. Cet appel API serait considéré comme légitime et passerait à travers ces contrôles de sécurité.
Les WAF et les passerelles API prennent parfois en charge des filtres de messages explicites et statiquement définis, souvent appelés approche de sécurité positive. Cependant, ces approches peuvent inhiber ou rompre les fonctionnalités métier, et la plupart des organisations les trouvent difficiles à opérationnaliser à grande échelle. Restreindre les méthodes HTTP est également une tâche plus facile que de restreindre les paramètres et les valeurs d'API, cette dernière nécessitant une expertise plus approfondie sur la conception de l'API.
L'activité dans l'exemple New Relic ci-dessus serait ignorée par les WAF et les passerelles API pour la même raison. Ces contrôles de sécurité ne sauraient pas que les applications tierces ne devraient plus avoir accès aux fonctions API obsolètes ou restreintes. Le réglage des contrôles aurait nécessité un transfert de connaissances approprié entre les équipes de développement, d'exploitation et de sécurité pour implémenter un filtre statique adéquat dans le proxy approprié au sein de l'architecture d'entreprise globale.
Comment protéger vos API contre les vulnérabilités d'autorisation au niveau des fonctions
Les solutions de sécurité API doivent être capables d'établir en continu une base de référence des modèles d'accès HTTP typiques par point de terminaison API et par utilisateur. Grâce à cette base de référence, les solutions de sécurité API peuvent identifier les appels avec des paramètres ou des méthodes HTTP inattendus envoyés à des points de terminaison API spécifiques, comme dans le premier exemple ci-dessus.
Il est essentiel qu'un outil de sécurité API soit capable d'établir une base de référence en continu, car les API peuvent subir un taux de changement élevé en raison des pratiques modernes de développement et de publication. Les solutions de sécurité API doivent être capables d'identifier et d'empêcher les attaquants ou les utilisateurs non autorisés d'accéder à des capacités de niveau administratif ou à des fonctionnalités non autorisées.
Pour en savoir plus sur la façon dont Salt peut aider à défendre votre organisation contre les risques liés aux API, vous pouvez contacter un représentant ou planifier une démonstration personnalisée.