Les attaques par API font régulièrement la une de l'actualité ces derniers temps. Il y a quelques semaines à peine, une grande entreprise de télécommunications en Australie a subi un incident de sécurité lié à ses API, exposant les données d'environ 10 millions de clients. En mars, une faille de l'API Hubspot a exposé les données sensibles de 1,6 million d'utilisateurs. Et qui pourrait oublier la vague de failles de sécurité API de 2021 qui a touché Peloton, John Deere et Experian ? La prédiction de Gartner selon laquelle « d'ici 2022, les abus d'API passeront d'un vecteur d'attaque rare au plus fréquent, entraînant des violations de données pour les applications web d'entreprise » s'est bel et bien réalisée.
Pourquoi assistons-nous à un flux aussi constant d'attaques basées sur les API ? Tout simplement parce que les API sont lucratives pour les attaquants. Elles agissent comme des agents de piste dans un aéroport, guidant les acteurs malveillants avec leurs bâtons lumineux directement vers les données les plus précieuses.
Comme les API sont également le moteur de l'économie numérique actuelle, cela pose un dilemme. Vous ne pouvez pas simplement décider de les supprimer ou de limiter leur accès sans freiner l'innovation de votre entreprise. Votre seule véritable option est de sécuriser vos API contre les attaques d'aujourd'hui — et de demain — pour garantir que votre entreprise puisse continuer à croître et à fournir les services attendus par vos clients.
De nombreuses organisations croient à tort que la « sécurité par l'obscurité » suffit à les protéger : elles pensent être suffisamment inconnues, que leurs données ne sont pas assez intéressantes, que leurs API sont différentes, et qu'elles sont donc en sécurité. Malheureusement, cette approche n'a jamais fonctionné et ne fonctionnera certainement pas dans ce monde hyperconnecté, où les données sont partout et où les API sont omniprésentes.
Qu'est-ce qu'une attaque par API ?
Une attaque par API est tout simplement une utilisation hostile — ou une tentative d'utilisation hostile — d'une API. Les attaquants utilisent un point de terminaison d'API pour accéder à des données et les exploiter. Parfois, ces attaques sont rendues possibles par un code fondamentalement médiocre. Mais le plus souvent, elles ciblent des vulnérabilités de la logique métier, en essayant de faire en sorte que les API se comportent d'une manière jamais prévue par leurs développeurs.
Pour compliquer encore les choses, chaque vulnérabilité d'API représente essentiellement une vulnérabilité de type « zero-day ». Comme les API de chaque entreprise sont uniques, les failles de sécurité diffèrent d'une API à l'autre. Par conséquent, pour découvrir comment exploiter efficacement les API, les attaquants doivent tâtonner — encore et encore — afin de déceler les erreurs de logique métier et d'identifier les vulnérabilités de l'API. Repérer ces attaques « lentes et discrètes », qui peuvent s'étaler sur des jours, des semaines, voire des mois, nécessite une analyse comportementale approfondie sur la durée.
En quoi les attaques par API actuelles sont-elles différentes ?
À mesure que le nombre d'API a augmenté, les menaces elles-mêmes ont évolué. Ce nouveau paradigme d'attaque est apparu parce que les API ont été construites sur la logique métier et la logique applicative sous-jacente. Comme mentionné, les risques les plus importants en matière de sécurité des API découlent de failles dans la logique métier.
Les attaques basées sur les transactions — comme une injection SQL classique — constituaient la majorité des attaques de sécurité par le passé. Les solutions de sécurité traditionnelles basées sur des proxys, comme un WAF, fonctionnent bien pour stopper ces types d'attaques ; les WAF recherchent des modèles connus et agissent comme un pare-feu, bloquant ce qui est identifié comme malveillant. Cependant, les approches de sécurité des API basées sur des serveurs ou des machines virtuelles ne disposent tout simplement pas d'un ensemble de données suffisamment large sur la durée pour identifier les attaques par API sophistiquées d'aujourd'hui.
Dans les attaques sur la logique applicative, les pirates utilisent la reconnaissance sur le long terme pour découvrir des failles dans la logique métier codée. Ils recherchent des zones à exploiter, comme l'obtention d'un accès non autorisé à des données ou à des fonctionnalités au sein de l'API, ou des faiblesses dans l'API pour lancer des attaques par déni de service (DoS) applicatif ciblées et à faible trafic.
C'est pourquoi les attaques proviennent rarement d'un seul appel API. Les attaquants effectuent de multiples appels API dans le cadre de leurs efforts de reconnaissance. Si les solutions de sécurité traditionnelles peuvent se défendre contre les vulnérabilités connues, elles ne peuvent pas détecter ces vulnérabilités logiques des API. Elles manquent de la compréhension nécessaire des fonctions et de la logique métier.
Pour protéger les API, les organisations doivent être capables de repérer les vulnérabilités logiques. Cela nécessite un contexte lié aux fonctions et à la logique métier. Les équipes de sécurité doivent observer les points de terminaison (endpoints) de l'API en action et comprendre la finalité fonctionnelle de chacun d'entre eux. Elles doivent également comprendre les caractéristiques comportementales de chaque paramètre et élément utilisé par ces points de terminaison. Un seul point de terminaison API peut présenter des milliers de permutations possibles de logique métier et applicative sous-jacente, qui doivent être examinées et testées pour déterminer si le point de terminaison est susceptible d'adopter des comportements malveillants.
Quels sont les types d'attaques API les plus courants ?
L'Open Web Application Security Project (OWASP), l'organisation à l'origine du Top 10 des vulnérabilités, a effectué un travail considérable pour aider le marché à comprendre les attaques de sécurité API les plus courantes aujourd'hui. Fin 2019, l'OWASP a publié son tout premier Top 10 de la sécurité des API répertoriant les vulnérabilités, incluant les dix types d'attaques API suivants :
- API1:2019 Autorisation défaillante au niveau de l'objet: L'autorisation défaillante au niveau de l'objet est la menace API la plus courante, représentant environ 40 % de toutes les attaques API.
- API2:2019 Authentification utilisateur défaillante: L'authentification utilisateur défaillante permet aux attaquants d'utiliser des jetons d'authentification volés, le bourrage d'identifiants (credential stuffing) et des attaques par force brute pour obtenir un accès non autorisé aux applications.
- API3:2019 Exposition excessive de données: Lorsque des API génériques fournissent plus de données que nécessaire, un attaquant peut exploiter une application en utilisant ces données redondantes pour extraire davantage d'informations sensibles.
- API4:2019 Manque de ressources et limitation de débit: Les API qui implémentent incorrectement la limitation de débit ou qui omettent de le faire sont très vulnérables aux attaques par force brute.
- API5:2019 Autorisation défaillante au niveau de la fonction: Lorsque l'autorisation n'est pas correctement implémentée, des utilisateurs non autorisés peuvent exécuter des fonctions API telles que l'ajout, la mise à jour ou la suppression d'un enregistrement client ou d'un rôle utilisateur.
- API6:2019 Assignation de masse: Les API qui consomment directement les requêtes d'entrée et les assignent ou les écrivent dans les magasins de données de logique métier sont vulnérables à l'assignation de masse, permettant aux attaquants de modifier des propriétés de données critiques et d'exploiter une élévation de privilèges.
- API7:2019 Configuration de sécurité incorrecte: La configuration de sécurité incorrecte est un terme générique désignant un large éventail d'erreurs de configuration qui nuisent souvent à la sécurité globale des API et introduisent des vulnérabilités par inadvertance.
- API8:2019 Injection: Cette attaque est la seule rescapée de la liste originale OWASP Top 10 ; les 90 % restants sont nouveaux et se concentrent exclusivement sur les API. Les attaquants exploitent les vulnérabilités par injection en envoyant des données malveillantes à une API, qui sont ensuite traitées par un interpréteur ou analysées par le serveur d'application, puis transmises à un service intégré.
- API9:2019 Gestion inappropriée des actifs: Un inventaire obsolète ou incomplet entraîne des failles inconnues dans la surface d'attaque des API et rend difficile l'identification des anciennes versions d'API qui devraient être mises hors service.
- API10:2019 Journalisation et surveillance insuffisantes: Une journalisation et une surveillance insuffisantes, combinées à une intégration manquante ou inefficace avec la réponse aux incidents, permettent aux attaquants d'effectuer des reconnaissances, d'exploiter ou d'abuser des API, de compromettre des systèmes, de maintenir une persistance, de faire progresser leurs attaques et de se déplacer latéralement dans les environnements sans être détectés.
Malheureusement, le rapport Salt Security Q3 2022 State of API Security a indiqué que seuls 55 % des répondants s'appuient sur la liste des 10 principales attaques d'API de l'OWASP. Étant donné que 62 % des tentatives d'attaque contre les organisations exploitent au moins l'une de ces méthodes, il s'agit d'une opportunité manquée.
Mes outils actuels sont-ils suffisants pour protéger notre surface d'attaque API ?
Comme nous l'avons évoqué, les API nécessitent une nouvelle approche de la sécurité avec des solutions dédiées s'appuyant sur une architecture qui va au-delà des outils traditionnels, limités à l'examen des transactions individuelles de manière isolée.
Dans une récente note de recherche, Gartner a reconnu le besoin de solutions dédiées en ajoutant la sécurité des API comme un niveau distinct dans son architecture de référence de sécurité mise à jour. Ce nouveau niveau se situe entre les outils traditionnels tels que les WAF, WAAP, passerelles API et CDN qui protègent la périphérie, et les outils qui protègent les données et le plan de contrôle. Avec cette nouvelle architecture, Gartner confirme que ces outils traditionnels laissent des lacunes dans la protection des API.
Pour protéger leurs API, les organisations ont besoin d'une plateforme spécifiquement créée pour répondre aux considérations de sécurité uniques des API d'aujourd'hui, incluant :
- Visibilité: La prolifération des API se poursuit sans relâche, rendant presque impossible la mise à jour sur les API nouvelles et modifiées. Les organisations ont également besoin d'informations sur les endroits où leurs API exposent des données sensibles.
- Prévention des attaques: Chaque API est unique, les attaques le sont donc aussi. Les organisations doivent être capables de détecter les comportements lents et discrets des acteurs malveillants qui sondent les API à la recherche de failles dans la logique métier.
- Sécurité proactiveLes informations de remédiation, issues des tests de pré-production ainsi que de l'exécution, aident les développeurs à renforcer leurs API. Les organisations ne doivent pas trop compter sur les tactiques de « shift-left ». Cependant, les tests de pré-production ne permettront pas de découvrir les failles de logique métier ; on ne peut donc pas attendre des développeurs qu'ils créent des API sécurisées à chaque fois.
Pour prévenir les attaques par API, vous devez d'abord savoir quelles API vous possédez
Une vision précise de la surface d'attaque est essentielle pour orienter votre stratégie de sécurité, mais cela peut s'avérer particulièrement difficile avec des API en constante évolution. En fait, une récente étude de Salt Security a révélé que 11 % des répondants mettaient à jour leurs API quotidiennement et 31 % chaque semaine.
Vous devez découvrir toutes les API de votre environnement, y compris les API fantômes inconnues, comme dans l'exemple ci-dessus, et les API zombies qui devraient être obsolètes. La découverte doit être automatique et continue pour suivre le rythme des nouvelles API et des mises à jour constantes, et doit couvrir toutes les API destinées aux clients, aux partenaires (fournies et consommées) et aux usages internes.
Savoir qu'une API existe ne suffit pas. Comprendre chaque API de manière granulaire est essentiel pour saisir la fonctionnalité prévue, évaluer les risques et déterminer si l'API expose des données sensibles telles que des informations personnellement identifiables (PII). Une découverte automatique et continue permet de garantir que la vision de la surface d'attaque et de l'exposition des données sensibles reste à jour à tout moment.
Le Big Data à l'échelle du cloud et les modèles d'IA matures aident à prévenir les attaques par API
Les attaquants ciblant les API utilisent des méthodes subtiles pour découvrir et exploiter les vulnérabilités. Prenons l'exemple de fraudeurs tentant de rediriger des virements ACH vers d'autres numéros de compte non autorisés. Les fraudeurs pourraient exploiter une vulnérabilité courante des API et manipuler les numéros de routage en modifiant seulement quelques paramètres d'API.
Pour détecter cela, vous avez besoin d'une solution qui combine Big Data, IA et ML pour capturer tout le trafic API, établir une base de référence de l'activité normale et rechercher les écarts. Dans le cas ci-dessus, ce type de solution identifierait la manipulation subtile du numéro de routage et signalerait l'activité.
Seule une architecture Big Data à l'échelle du cloud dotée d'intelligence artificielle (IA) et d'apprentissage automatique (ML) peut capturer et analyser en continu de grands volumes de trafic API. L'analyse continue du trafic API est le seul moyen de comprendre le comportement normal de chaque API unique et d'obtenir le contexte nécessaire pour identifier les écarts subtils et localiser les attaquants.
La protection des API nécessite également une analyse du trafic API dans le temps. Par nature, les API exposent la logique applicative. Les pirates expérimentent beaucoup pour tenter d'identifier les failles de logique métier qu'ils peuvent exploiter. La reconnaissance nécessaire pour propager de telles attaques prend beaucoup de temps. Une seule attaque par API peut prendre des heures, des jours, voire des semaines à se dérouler.
Une fois que vous avez stoppé l'hémorragie, il est temps d'éliminer les failles futures
Les équipes DevOps jouent un rôle essentiel dans la sécurité, mais tout logiciel sera inévitablement publié avec des failles, malgré l'application des meilleures pratiques de développement et l'utilisation d'outils d'analyse par les équipes. Les API ne font pas exception. Les pratiques de développement agile et les cycles de publication serrés signifient que les équipes de développement, sous pression, peuvent négliger la sécurité pour respecter des délais stricts.
La protection à l'exécution est cruciale pour empêcher l'exploitation de toute vulnérabilité atteignant la production. Mais compter uniquement sur la protection à l'exécution vous place dans une situation de jeu du chat et de la souris. Les failles doivent être continuellement identifiées et éliminées par les équipes de développement pour améliorer la sécurité des API.
Les solutions de sécurité API leaders d'aujourd'hui peuvent bloquer les fraudeurs et apprendre de leur activité pendant qu'ils sondent et manipulent l'API. Ces enseignements fournissent ensuite des informations sur les vulnérabilités propres à cette API et aident les équipes de développement à prioriser et à éliminer rapidement les failles.
C'est une course permanente ! Les solutions de sécurité API doivent analyser les API pour identifier les failles avant qu'un attaquant ne les trouve et permettre aux développeurs d'éliminer proactivement les vulnérabilités potentielles tout en affinant simultanément leurs meilleures pratiques de sécurité API.
Pour plus d'informations
Contactez-nous ou planifier une démo personnalisée pour en savoir plus sur la façon dont la plateforme de protection des API de Salt Security peut aider votre organisation à établir un inventaire complet et précis de ses API, à détecter les attaques en temps réel et à obtenir des informations exploitables pour corriger les vulnérabilités et renforcer vos API.