Les codeurs conquièrent la série d'API Top 10 de l'OWASP en matière de sécurité - Contrôle d'accès au niveau des fonctions manquant

Cette série de blogs se concentrera sur certaines des pires vulnérabilités liées aux interfaces de programmation d'applications (API). Ils sont si mauvais qu'ils ont créé l'Open Web Application Security Project (GUÊPE) liste des principales vulnérabilités des API. Compte tenu de l'importance des API pour les infrastructures informatiques modernes, il s'agit de problèmes critiques que vous devez à tout prix éviter dans vos applications et programmes.

Le contrôle d'accès au niveau des fonctions manquant Une vulnérabilité permet aux utilisateurs d'exécuter des fonctions qui devraient être restreintes ou leur permet d'accéder à des ressources qui doivent être protégées. Normalement, les fonctions et les ressources sont directement protégées dans le code ou par les paramètres de configuration, mais ce n'est pas toujours facile de le faire 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 participer à notre défi gamifié pour voir où vous en êtes dans cette catégorie délicate de bugs ?

Jetons un coup d'œil plus approfondi :

Les API sont particulièrement vulnérables à cette faille car elles sont très structurées. Les attaquants qui comprennent le code peuvent deviner en toute connaissance de cause comment implémenter des commandes qui devraient leur être réservées. C'est l'une des principales raisons pour lesquelles la vulnérabilité du contrôle d'accès au niveau des fonctions/ressources s'est classée dans le top 10 de l'OWASP.

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

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

L'OWASP donne un exemple de cette vulnérabilité d'un processus d'enregistrement mis en place pour permettre aux nouveaux utilisateurs de rejoindre un site Web. Il utiliserait probablement un appel d'API GET, comme celui-ci :

GET /api/invites/ {invite_guid}

L'utilisateur malveillant récupérerait un JSON contenant les détails de l'invitation, y compris le rôle et l'adresse e-mail de l'utilisateur. Ils pourraient ensuite changer GET en POST et également faire passer leur invitation d'utilisateur à administrateur à l'aide de l'appel d'API suivant :

POSTER /api/invites/nouveau
{"email » : » shadyguy@targetedsystem.com «, "role » :"admin "}

Seuls les administrateurs devraient être en mesure d'envoyer des commandes POST, mais si elles ne sont pas correctement sécurisées, l'API les considérera comme légitimes et exécutera 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, ils pourraient voir et faire tout ce qu'un administrateur légitime pourrait faire, ce qui ne serait pas une bonne chose.

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

Il est particulièrement important de prévenir cette vulnérabilité d'API, 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'ils peuvent obtenir un certain niveau d'accès à une API, ils peuvent commencer à cartographier la structure du code et à créer des appels qui seront éventuellement suivis.

Par conséquent, toutes les fonctions au niveau de l'entreprise 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 fonctionne pas ou si la routine qu'il contient est difficile à implémenter, de nombreux modules externes sont spécialement conçus pour une utilisation facile. Quelle que soit la méthode que vous choisissez finalement, veillez à implémenter l'autorisation sur le 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, n'oubliez pas que les utilisateurs ne doivent être autorisés qu'à faire ce dont ils ont besoin et rien de plus. Comme c'est toujours le cas lorsque vous codez des API ou quoi que ce soit d'autre, pratiquez la méthodologie du moindre privilège. Cela sécurisera votre environnement et évitera de nombreux problèmes liés à la cybersécurité à l'avenir.

Consultez le Secure Code Warrior pages de blog pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients des ravages causés par d'autres failles de sécurité. Vous pouvez également essayez une démo de la plateforme de formation Secure Code Warrior pour maintenir toutes vos compétences en cybersécurité à jour et à jour.