Série Coders Conquer Security OWASP Top 10 API - Absence de contrôle d'accès au niveau des fonctions

Cette série d'articles se concentrera sur certaines des pires vulnérabilités liées aux interfaces de programmation d'applications (API). Elles sont si graves qu'elles figurent sur la liste des principales vulnérabilités API de l'Open Web Application Security Project (OWASP). Compte tenu de l'importance des API pour les infrastructures informatiques modernes, il s'agit de problèmes critiques que vous devez absolument éviter dans vos applications et programmes.

La vulnérabilité liée à l'absence de contrôle d'accès au niveau des fonctions permet aux utilisateurs d'exécuter des fonctions qui devraient être restreintes, ou d'accéder à des ressources qui devraient être protégées. Normalement, les fonctions et les ressources sont directement protégées dans le code ou par des paramètres de configuration, mais ce n'est pas toujours facile à réaliser correctement. La mise en œuvre de contrôles appropriés peut s'avérer difficile car les applications modernes contiennent souvent de nombreux types de rôles et de groupes, ainsi qu'une hiérarchie d'utilisateurs complexe.

Mais d'abord, pourquoi ne pas vous lancer et participer à notre défi ludique pour évaluer votre maîtrise de cette catégorie de bugs complexe ?

Examinons cela plus en détail :

Les API sont particulièrement vulnérables à ce défaut car elles sont hautement structurées. Les attaquants qui comprennent le code peuvent deviner comment implémenter des commandes qui devraient leur être restreintes. C'est l'une des principales raisons pour lesquelles la vulnérabilité de contrôle d'accès au niveau des fonctions/ressources figure dans le top 10 de l'OWASP.

Comment les attaquants peuvent-ils exploiter la vulnérabilité de contrôle d'accès au niveau des fonctions ?

Les attaquants qui soupçonnent que des fonctions ou des ressources ne sont pas correctement protégées doivent d'abord obtenir l'accès au système qu'ils souhaitent attaquer. Pour exploiter cette vulnérabilité, ils doivent avoir la permission d'envoyer des appels API légitimes vers le point de terminaison. Il existe peut-être une fonction d'accès invité de bas niveau ou un moyen de se connecter anonymement dans le cadre des fonctionnalités de l'application. Une fois cet accès établi, ils peuvent commencer à modifier les commandes dans leurs appels API légitimes. Par exemple, ils pourraient remplacer GET par PUT, ou changer la chaîne USERS dans l'URL par ADMINS. Encore une fois, comme les API sont structurées, il est facile de deviner quelles commandes pourraient être autorisées et où les placer dans la chaîne.

L'OWASP donne un exemple de cette vulnérabilité avec un processus d'inscription configuré pour permettre aux nouveaux utilisateurs de rejoindre un site web. Il utiliserait probablement un appel API GET, comme ceci :

GET /api/invites/{invite_guid}

L'utilisateur malveillant recevrait un JSON contenant des détails sur l'invitation, y compris le rôle et l'e-mail de l'utilisateur. Il pourrait alors remplacer GET par POST et élever son invitation d'utilisateur à administrateur en utilisant l'appel API suivant :

POST /api/invites/new
{"email":"shadyguy@targetedsystem.com","role":"admin"}

Seuls les administrateurs devraient pouvoir envoyer des commandes POST, mais si elles ne sont pas correctement sécurisées, l'API les acceptera comme légitimes et exécutera tout ce que l'attaquant souhaite. Dans ce cas, l'utilisateur malveillant serait invité à rejoindre le système en tant que nouvel administrateur. Après cela, il pourrait voir et faire tout ce qu'un administrateur légitime peut faire, ce qui ne serait pas une bonne chose.

Éliminer la vulnérabilité de contrôle d'accès au niveau des fonctions

La prévention de cette vulnérabilité API est particulièrement importante car il n'est pas difficile pour un attaquant de trouver des fonctions non protégées au sein d'une API structurée. Tant qu'il peut obtenir un certain niveau d'accès à une API, il peut commencer à cartographier la structure du code et créer des appels qui seront finalement exécutés.

Par conséquent, toutes les fonctions métier doivent être protégées à l'aide d'une méthode d'autorisation basée sur les rôles. La plupart des frameworks proposent des routines centralisées pour y parvenir. Si le framework que vous avez choisi ne le fait pas, ou si la routine intégrée est difficile à mettre en œuvre, il existe de nombreux modules externes conçus spécifiquement pour une utilisation facile. Quelle que soit la méthode choisie, assurez-vous d'implémenter l'autorisation côté serveur. N'essayez jamais de sécuriser les fonctions côté client.

Lorsque vous créez des autorisations au niveau des fonctions et des ressources, gardez à l'esprit que les utilisateurs ne doivent recevoir que les permissions nécessaires à leurs tâches, rien de plus. Comme toujours lors du codage d'API ou autre, appliquez le principe du moindre privilège. Cela sécurisera votre environnement et évitera de nombreux problèmes de cybersécurité à l'avenir.

Consultez les pages du blog Secure Code Warrior pour plus d'informations sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients contre les ravages d'autres failles de sécurité. Vous pouvez également essayer une démo de la plateforme de formation Secure Code Warrior pour garder toutes vos compétences en cybersécurité aiguisées et à jour.