Quelles sont les cinq vulnérabilités courantes des API ?

L'API facilite les affaires, et les pirates informatiques le pensent aussi. Aujourd'hui, alors que la transformation numérique des entreprises bat son plein, les API dépassent largement le cadre de l'innovation technologique des entreprises Internet et la transformation numérique des entreprises traditionnelles est indissociable de l'économie ou de la stratégie des API. Les API connectent non seulement les systèmes et les données, mais également les services fonctionnels de l'entreprise, les clients et les partenaires, voire l'ensemble de l'écosystème commercial. Dans le même temps, face aux menaces de sécurité de plus en plus graves, les API deviennent la prochaine frontière de la sécurité des réseaux. Nous avons compilé les cinq principales faiblesses de sécurité des API et les suggestions de correctifs proposées par les experts en sécurité aux entreprises.

Les API facilitent tout, du partage de données à la connectivité du système en passant par la fourniture de fonctions critiques, mais les API facilitent également la tâche des attaquants, y compris des robots malveillants. La prolifération des applications API incite les cybercriminels à exploiter de plus en plus les vulnérabilités de sécurité des API pour commettre des fraudes et voler des données.

Ci-dessous, nous discuterons de cinq vulnérabilités d'API qui sont facilement exploitées par les pirates informatiques, et partagerons les suggestions d'atténuation et de renforcement données par des experts en sécurité.

1. Trop facile à découvrir

Si vous êtes un hacker et que vous comptez attaquer une entreprise, la première chose à faire est d'identifier le plus d'API possible. J'utilise d'abord l'application cible de manière normale, en ouvrant l'application Web dans un navigateur ou en téléchargeant et en installant l'application mobile sur le téléphone, puis j'utilise un proxy d'interception pour surveiller la communication.

Le proxy d'interception est capable de capturer toutes les requêtes faites par le navigateur ou l'application mobile au serveur Web backend, permettant à l'attaquant de cataloguer tous les points de terminaison d'API disponibles. Par exemple, la plupart des API ont API/V1/login comme point de terminaison d'authentification.

Si la cible est également une application mobile, décompressez l'application et consultez les appels API disponibles dans l'application. En prenant en compte toutes les activités possibles, les attaquants peuvent rechercher des erreurs de configuration courantes ou des API qui ne parviennent pas à protéger correctement les données des utilisateurs.

Enfin, l'attaquant recherche la documentation de l'API. Certaines organisations publient de la documentation API pour des tiers mais utilisent les mêmes points de terminaison API pour tous les utilisateurs.

Avec une bonne liste de points de terminaison, les attaquants peuvent tester à la fois le comportement standard des utilisateurs et les tests de comportement anormal, trouvant des vulnérabilités intéressantes dans les deux sens.

Solution de contournement : Pour rendre l'API plus difficile à découvrir pour les attaquants, assurez-vous de contrôler l'accès à la documentation de l'API via une gestion des autorisations qui autorise uniquement l'accès des utilisateurs valides. Bien que l’épinglage du certificat sur l’application mobile ne masque pas complètement le point de terminaison de l’API et que ce ne soit pas parfait, cela ajoute une étape supplémentaire à l’attaque. Les requêtes API adressées au serveur Web doivent être masquées et contrôlées autant que possible.

2. Messages d'erreur trop détaillés

Récemment, les tentatives d'attaquants pour s'emparer des comptes se sont multipliées. Les messages d'erreur trop « détaillés » ont tendance à faciliter de telles attaques. Le long message d'erreur guide l'attaquant sur les modifications qu'il doit apporter pour apparaître comme une demande légitime. L'API est conçue pour les transactions à grande vitesse sous faible charge, permettant aux attaquants d'utiliser des systèmes hautes performances pour identifier les comptes valides, puis de tenter de se connecter et de modifier les mots de passe à des fins d'exploitation.

Solution : N'utilisez pas l'expérience utilisateur comme bouclier. Certaines pratiques qui semblent bonnes pour l'expérience utilisateur peuvent ne pas l'être pour la sécurité. Le message d'erreur renvoyé par le système ne doit pas inclure un mauvais nom d'utilisateur ou un mauvais mot de passe, ni même la catégorie du message d'erreur (mauvais nom d'utilisateur ou mot de passe). Il en va de même pour les messages d'erreur utilisés pour interroger des données. Si la requête/recherche est mal formée ou ne peut pas être exécutée pour une raison quelconque, elle devrait renvoyer le message d'erreur le plus « peu nutritif » : « Oups, quelque chose s'est mal passé ».

3. Trop de paramètres

Lorsqu'un attaquant traverse le système d'attaque via des appels API, il doit déterminer ce qu'il peut envoyer pour obtenir les données. Les attaquants « croient » que plus le système est complexe, plus les choses peuvent mal tourner. Une fois que l'attaquant aura identifié l'API, il cataloguera les paramètres puis tentera d'accéder aux données d'un administrateur (élévation de privilèges verticale) ou d'un autre utilisateur (élévation de privilèges horizontale) pour collecter des données supplémentaires. Souvent, trop de paramètres inutiles sont exposés à l’utilisateur.

Dans un projet de recherche récent, nos appels API au service cible ont renvoyé une grande quantité de données, dont une grande partie étaient des informations inutiles, telles que les clés du processeur de la passerelle de paiement et les informations sur les remises disponibles. Ces « informations de récompense » permettent aux attaquants de mieux comprendre le contexte et la syntaxe de ces appels API. Il ne faut pas beaucoup d’imagination à l’attaquant pour savoir quoi faire ensuite. Ces paramètres supplémentaires fournissent aux attaquants un riche ensemble de données d’attaque.

Solution de contournement : Si vous limitez la portée du contenu que les utilisateurs voient à ce qui est requis, limitez la transmission des données critiques et rendez la structure des requêtes de données inconnue, il sera difficile pour les attaquants de forcer brutalement les paramètres qu'ils connaissent.

4. Trop de données

Encore une fois, avec autant de paramètres disponibles, la collecte de données sera la prochaine étape évidente. De nombreux systèmes d'entreprise prennent en charge les connexions anonymes et ont tendance à divulguer des données supplémentaires dont l'utilisateur moyen n'a pas besoin. De plus, de nombreuses entreprises préfèrent stocker des données accessibles directement.

Les professionnels de la sécurité sont aux prises avec le défi des requêtes API révélant souvent l'endroit où les données sont stockées. Par exemple, lorsque je visionne une vidéo provenant d'une caméra de sécurité, je peux voir que les informations proviennent d'un référentiel Amazon S3. Souvent, ces référentiels S3 ne sont pas bien protégés et les données de n'importe qui peuvent être récupérées.

Un autre défi courant en matière de données est la surcharge de données. De nombreuses entreprises sont comme des tamias avant l'hiver, stockant bien plus de données qu'elles n'en ont besoin. De nombreuses données utilisateur expirées n’ont aucune valeur commerciale ni valeur de conservation, mais en cas de fuite, elles entraîneront d’énormes risques de marque et de conformité pour l’entreprise.

Solution : Pour les entreprises qui stockent des données utilisateur, pas seulement des données PII ou PHI, un examen approfondi des données est requis. Après avoir examiné les données stockées, des règles d'accès aux données doivent être développées et testées. Assurez-vous que les données accessibles de manière anonyme n’impliquent aucune donnée sensible.

5. Trop peu de conception de sécurité

Pendant de nombreuses années, la conception d'applications a toujours donné la priorité à la fonctionnalité et à la convivialité, prenant rarement en compte la sécurité. De nombreux RSSI affirment que la sécurité des API en particulier n'est pas prise au sérieux, voire complètement exclue du processus de conception de la sécurité. Habituellement, une fois que les développeurs ont terminé le développement et le déploiement, ils n'essaient de détecter les problèmes qu'une fois l'API mise en production et fréquemment attaquée. La sécurité (y compris la sécurité des API) doit faire partie de la conception du produit et être mise en œuvre comme l'une des premières considérations, et non après coup.

Solution : Revoir l'architecture de sécurité de votre application est une première étape importante vers un système sécurisé. N'oubliez pas que les API permettent aux attaquants d'attaquer ou d'exploiter votre système plus efficacement. L'objectif de la conception de la sécurité est de faire de l'API un outil efficace pour les utilisateurs plutôt que pour les attaquants.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!