On me pose souvent des questions sur les API fantômes et les paramètres d'API fantômes, même par des personnes ayant une grande expérience dans le domaine du développement d'API. Ce n'est pas très surprenant, car les API fantômes ne constituent pas un risque auquel on pense dans le cadre du développement normal d'une API. En fait, certaines personnes sont convaincues que les API fantômes ne sont qu'une tactique de peur utilisée par les fournisseurs de sécurité pour vendre leurs outils.
Cependant, en réalité, les API virtuelles sont relativement faciles à construire et à utiliser. Quel est le meilleur moyen de mieux les comprendre ? En examinant des exemples concrets ! C'est donc ce que nous allons aborder dans ce billet.
Qu'est-ce qu'une API fantôme ?
Commençons par cet exemple de demande d'API que j'ai rencontré :
Il s'agit d'une requête à une API GraphQL pour générer le mot de passe à usage unique (OTP) utilisé pour l'authentification d'un service web. Si vous ne regardez pas attentivement, vous risquez de ne pas voir le problème, c'est pourquoi je l'ai marqué d'une grosse flèche rouge. Ce problème otpDigit est en fait un problème majeur.
J'ai découvert que ce paramètre est en fait modifiable via l'API. En le modifiant, vous pouvez ajuster la longueur du mot de passe à usage unique requis pour l'authentification. Quelles sont les conséquences ? J'ai pu modifier la valeur en la ramenant à 1. Le nombre de possibilités pour le mot de passe est ainsi passé d'un million à seulement 10 !
Naturellement, l'équipe de développement a été alarmée lorsque je lui ai parlé de ce paramètre, et elle l'a corrigé immédiatement. Néanmoins, il s'agit là d'un parfait exemple d'API fantômes et de leurs paramètres. Il est très probable que ce paramètre était une commodité initiale pour les développeurs, utilisée à des fins de prototypage ou de test. Lorsque l'API est passée en production, la prise en charge du paramètre n'a jamais été supprimée et il est devenu un paramètre d'API fantôme.
Cette vulnérabilité majeure n'aurait pas été découverte si personne n'avait cherché à savoir ce qu'il était possible de faire avec un paramètre non documenté. Plus important encore, une équipe de développement ne fera pas de recherches approfondies avant d'être confrontée à cette vulnérabilité.
Cet exemple jette les bases d'une directive de travail concernant les points de terminaison et les paramètres de l'API qui se trouvent dans l'ombre : Tous les points de terminaison ou paramètres de votre API qui ne sont pas directement sous les projecteurs des développeurs existent dans l'ombre, et ils présentent un risque car l'équipe de sécurité les négligera probablement aussi.
Que puis-je faire au sujet des API fantômes ?
Maintenant que vous savez ce que sont les points de terminaison et les paramètres de l'API fantôme, la question suivante est de savoir ce que vous pouvez faire à ce sujet. Il est évident que vous ne pouvez pas simplement dire à votre équipe de sécurité d'être plus vigilante, surtout en ce qui concerne les éléments que les développeurs ne mettent même pas en évidence dans leur travail actif.
Il est fort probable que vous ayez besoin d'un outil ou d'un processus pour vous aider à évaluer la sécurité de vos API. Le type d'outil dont vous avez besoin dépend de la taille de votre entreprise et du nombre d'API que vous avez déployées. Les passerelles API ou même les outils de sécurité API peuvent vous aider à atteindre le degré de sécurité dont vous avez besoin, mais ils peuvent être plus nombreux que ce dont vous avez besoin. Si vous n'avez que quelques points d'extrémité disponibles pour les consommateurs d'API, le déploiement d'un ensemble robuste d'outils qui suivent le trafic à travers votre pile et vous alertent en cas d'activité suspecte est certainement exagéré.
Une approche plus simple consiste à s'assurer que vos API sont bien documentées. C'est également un bon point de départ. Commencez par adopter la norme OpenAPI pour documenter vos API. N'oubliez pas que les API fantômes naissent lorsque vous ne prêtez pas attention à vos points de terminaison et à vos paramètres. L'objectif de la norme OpenAPI est de fournir un modèle vous permettant de spécifier - et donc de connaître - chaque point de terminaison et chaque paramètre de votre API.
À partir de là, vous pouvez également demander à vos développeurs de fournir cette documentation sur l'API à l'équipe de sécurité lors du déploiement. L'équipe de sécurité teste alors l'API par rapport à la documentation, afin de détecter toute inexactitude ou lacune. Cela permet d'éviter les angles morts.
Conclusion
Les choses ne resteront pas dans l'ombre si vous éclairez ces espaces. En fin de compte, si vous connaissez les détails des API que vous avez déployées, les API fantômes ne peuvent pas exister. Bien que ce ne soit peut-être pas la tâche la plus excitante au monde, documenter vos API vous aidera à éviter de les ouvrir à des attaquants malveillants.
Nous espérons que cet article vous a éclairé sur la définition et les dangers des API fantômes. Go éclaire les zones d'ombre de votre infrastructure d'API afin d'éviter les failles de sécurité !
Commentaires