Découvrez GoogleTest certifié TÜV avec Agentic AI pour les tests C/C++ !
Plus de détails »
Livre blanc
Vous vous demandez ce que contient le guide ? Commencez par consulter l’aperçu ci-dessous.
Les adversaires d'aujourd'hui sont guidés par un objectif précis : voler des secrets commerciaux, des informations personnelles sur les consommateurs ou nuire à une entreprise par une attaque par déni de service. Découvrir des vulnérabilités zero-day et attaquer des applications personnalisées est complexe. Un vecteur d'attaque plus simple est toujours préférable, qu'il s'agisse d'attaquer un fournisseur au sein d'une chaîne d'approvisionnement aux pratiques de sécurité logicielle défaillantes, d'amener un utilisateur à divulguer des identifiants confidentiels ou d'exploiter une vulnérabilité connue dans un composant logiciel libre courant.
Les API représentent plus de 80 % du trafic web et offrent aux attaquants des techniques d'attaque similaires à celles des logiciels libres vulnérables.
Bien souvent, les problèmes à l'origine des failles de sécurité liées aux API ne sont pas dus à une intelligence ou une diligence particulière de la part de l'attaquant (et parfois même du chercheur en sécurité). En réalité, nombre de ces problèmes sont liés à une conception et une implémentation défaillantes de l'API.
Les principes fondamentaux de la sécurité logicielle sont l'authentification et l'autorisation fortes, le principe du moindre privilège et la protection des données, ainsi que la détection des abus et des utilisations malveillantes. Les récentes failles de sécurité chez Clubhouse, John Deere et Experian illustrent le non-respect des pratiques de sécurité logicielle de base, entraînant la fuite d'informations sur les utilisateurs, les clients et les consommateurs.
« Les API mal conçues peuvent perturber les entreprises et éroder la confiance des consommateurs, en particulier lorsqu'elles révèlent des problèmes de confidentialité. »
—Expert en solutions de sécurité chez Parasoft
« Des API mal conçues peuvent perturber les activités des entreprises et éroder la confiance des consommateurs, notamment lorsqu'elles révèlent des problèmes de confidentialité. Les vulnérabilités de l'API Clubhouse, qui permettent le ghosting, le trolling et l'écoute clandestine, illustrent pourquoi la sécurité doit être intégrée dès la conception et respecter les bonnes pratiques d'ingénierie logicielle, où le principe du moindre privilège est fondamental pour éliminer toute une catégorie de problèmes de sécurité », explique l'expert en solutions de sécurité chez Parasoft.
Dans chaque cas, les chercheurs en sécurité ayant identifié les vulnérabilités ont simplement utilisé l'API, conformément à sa conception, pour accéder aux informations de millions d'utilisateurs et/ou de clients, et ont même détourné les fonctionnalités prévues. Certaines API étaient accessibles à tout utilisateur sans authentification et permettaient de consulter n'importe quel utilisateur (ou tous) et de télécharger leurs noms, adresses, achats et autres informations. Il s'agissait d'erreurs évitables lors de la conception, de la mise en œuvre et des tests des API.
Une API bien conçue nécessite la contribution des responsables produit, des architectes et des experts en sécurité afin de bien comprendre les cas d'abus et de mauvaise utilisation et d'intégrer la sécurité dès la conception. Comme l'illustrent les exemples précédents, les contrôles d'authentification sont essentiels, car le mécanisme d'authentification est accessible à tous, y compris aux adversaires de l'organisation.
Les contrôles d'authentification ne se limitent donc pas à exiger l'authentification des utilisateurs et des systèmes. Ils comprennent des mesures visant à prévenir le bourrage d'identifiants et les attaques par force brute, les mots de passe faibles et la divulgation d'informations sensibles telles que les jetons d'authentification et les clés de chiffrement faibles.
Des contrôles d'authentification forts ne constituent qu'une première étape. Comme l'ont souligné les Top 10 de la sécurité de l'API OWASPLes organisations doivent également veiller à ce que les autorisations soient appropriées tant au niveau de l'objet qu'au niveau de la fonction.
La découverte des API est essentielle. Une visibilité complète sur toutes les API est indispensable. On ne peut sécuriser un système sans en connaître l'existence. Comprendre la surface d'attaque et identifier les API exposées est crucial pour les tests de sécurité. La couverture des tests et la découverte des API constituent des données importantes pour minimiser les risques liés aux attaques d'API. Comme mentionné précédemment, le passage des applications monolithiques aux microservices a considérablement augmenté le nombre d'API au sein des organisations. Cette évolution fondamentale exigera des organisations une approche plus proactive en matière de découverte des API et d'analyse de la surface d'attaque.
Idéalement, les projets logiciels incluent une documentation détaillée destinée aux équipes internes afin de simplifier la maintenance et d'aider les nouveaux développeurs à comprendre le fonctionnement de l'application. De même, les API nécessitent une documentation pour les développeurs qui les utilisent, qu'il s'agisse de développeurs et de testeurs internes ou de tiers. En réalité, la pression exercée pour ajouter des fonctionnalités et accélérer la mise sur le marché conduit souvent à une documentation limitée.
Cela est particulièrement vrai pour les API, généralement plus simples et destinées à un usage interne. Sans documentation interne adéquate, les ingénieurs DevOps ont une connaissance imparfaite du fonctionnement d'une API. En l'absence de contrats, de définitions et de spécifications d'API, les équipes d'assurance qualité et de sécurité doivent modéliser le comportement prévu des API et deviner les cas d'utilisation et de mésusage.
Les ressources en sécurité sont rares dans la plupart des organisations. C'est un problème national croissant. L'assurance qualité et l'ingénierie DevOps se concentrent généralement sur les tests fonctionnels, afin de garantir que les fonctionnalités décrites dans le cahier des charges fonctionnent conformément aux spécifications.
Bien que cela comprenne des cas d'utilisation comme les tests de débit et de capacité, cela peut passer à côté des tests de sécurité qui se concentrent souvent sur les cas d'abus et de mauvaise utilisation, comme l'appel d'une API avec des arguments intentionnellement erronés ou la mauvaise gestion des valeurs renvoyées par l'API.
Les équipes de sécurité et de test connaissent généralement bien les cas d'utilisation d'une interface utilisateur. Les cas d'utilisation d'une API sont plus complexes, notamment entre microservices.
Bien que les problèmes et vulnérabilités de sécurité mentionnés précédemment soient relativement simples, la multiplication rapide des microservices et des API qui en résultent complexifie la sécurité, permettant potentiellement à des attaquants sophistiqués de relier plusieurs API dans une attaque en plusieurs étapes. Les politiques de contrôle d'accès, avec leurs hiérarchies, groupes et rôles différents, peuvent dérouter les équipes de sécurité et conduire à des contrôles de sécurité insuffisants.
Tester et sécuriser les API Il est nécessaire de comprendre la logique d'une application, un sujet souvent mal connu des équipes de sécurité. Les API sont comparables à des briques Lego, modulables de multiples façons. Des attaquants peuvent les utiliser à des fins détournées, voire les exploiter pour attaquer une application. Par exemple, combien de manières existe-t-il d'accéder au panier d'achat ou aux informations de paiement stockées ?
« Les API sont étonnamment flexibles. Pouvoir tester l'ensemble des combinaisons possibles est essentiel pour garantir la sécurité de vos API. »
—Arthur Hicken, responsable de l'évangélisation chez Parasoft
Des tests complets nécessitent une visibilité programmatique sur les API et leurs interactions, les cas limites, les protocoles et la connaissance des types de données attendus. Créer des tests est possible avec des ressources suffisantes, bien sûr, mais cette compétence est très difficile à acquérir.
Les outils traditionnels utilisés de manière traditionnelle ne constituent qu'une solution partielle. Outils d'analyse statique Ces outils analysent généralement le code source. Bien qu'ils identifient certains problèmes liés à l'API, leur méconnaissance des fonctionnalités prévues limite leur exhaustivité.
Les scanners d'analyse dynamique sont également utiles, mais ils ne recherchent souvent que les points d'entrée dans l'interface utilisateur et peuvent ne pas avoir connaissance des API et de leurs fonctionnalités.
Bien qu'un testeur d'intrusion expérimenté puisse identifier les failles des API, cette méthode est difficilement applicable à grande échelle et peu pratique en termes de temps et de coûts. Elle est également incompatible avec les méthodologies de développement rapide telles que l'intégration continue/déploiement continu (CI/CD) et le DevSecOps.
Ces outils ne comprennent pas les mécanismes d'authentification API et doivent connaître les protocoles tels que OAuth2 et JSON Web Tokens.
Ces outils rencontrent également des difficultés avec les types de contenu et les réponses HTTP, ce qui influe sur la détection des vulnérabilités des API. De plus, ils ne disposent d'aucun lien permettant de découvrir les API, ce qui modifie fondamentalement les tests de sécurité de ces dernières.
L'ajout de Test de sécurité API L'intégration au cycle de vie du développement logiciel est possible, même dans des environnements de développement rapide, lorsque les organisations fournissent aux ingénieurs DevOps les outils et le soutien appropriés.
Il est essentiel que les tests de sécurité prennent en compte les défauts de conception courants, ainsi que les erreurs d'implémentation et de configuration. Développer des logiciels plus sécurisés n'est pas un secret : plusieurs lignes directrices et normes permettent aux organisations d'identifier et d'atténuer les risques.
L'une d'entre elles, la norme OWASP ASVS (Application Security Verification Standards), est particulièrement utile lors de la conception et de la mise en œuvre d'API. ASVS se décrit comme « une liste d'exigences ou de tests de sécurité des applications pouvant être utilisés par les architectes, les développeurs, les testeurs, les professionnels de la sécurité, les fournisseurs d'outils et les utilisateurs pour définir, construire, tester et vérifier des applications sécurisées ».
Bien que l'obtention de la certification ASVS soit un objectif admirable, les organisations qui cherchent à améliorer progressivement leurs programmes de sécurité logicielle peuvent utiliser les directives ASVS de manière moins formelle.
Intégration des activités de sécurité des API Il est possible d'intervenir dès les premières étapes du cycle de vie du développement logiciel, même dans des environnements de développement rapide, lorsque les organisations fournissent à leurs équipes de développement les outils et le soutien adéquats.
Il est essentiel de réaliser des tests de sécurité précoces pour prévenir et détecter les problèmes de sécurité des API, mais tout commence par une bonne conception. Concevoir une API sécurisée n'a rien de compliqué. Cela implique notamment de définir clairement les paramètres autorisés par les contrôles de sécurité, de mettre en place une limitation du débit pour prévenir les attaques par force brute et d'appliquer des mécanismes d'authentification robustes pour éviter toute utilisation abusive de l'API.
Reporter les tests de sécurité à une phase tardive du cycle de vie du développement logiciel engendre des retards et une augmentation des coûts. La correction des bogues devient plus onéreuse lors de la maintenance. Cette hausse des coûts est due, en grande partie, à la difficulté de remanier le logiciel pour corriger les bogues ou modifier les bibliothèques open source, tout en préservant les caractéristiques et fonctionnalités de la conception originale.
Dans les normes ASVS, l'approche « shift left » prend en compte les fonctionnalités des API, l'authentification et l'autorisation dès la phase de conception du cycle de vie. Cela implique d'authentifier les communications entre les composants de l'application, y compris les API ; d'appliquer le principe du moindre privilège à tous les composants ; de chiffrer les appels aux API ; et de veiller à ce que les URL des API ne divulguent aucune information sensible, comme les jetons de session.
L'OWASP fournit des recommandations via son Top 10 des API, qui décrit le consensus sur les vulnérabilités les plus courantes et les plus critiques des API. Nombre d'entre elles concernent la gestion des identités et des accès, tandis que d'autres, comme les failles d'injection et de journalisation, sont déjà exploitées et intégrées dans la plupart des suites de tests de sécurité applicatifs.
Une meilleure méthode pour tester les API consiste à tirer parti des tests fonctionnels pour fournir une visibilité sur les API sous-jacentes à l'application et leurs fonctionnalités, et à augmenter la génération de tests à l'aide de l'intelligence artificielle (IA) pour construire des cas de test appropriés.
"Test d'API « Cela peut s'avérer étonnamment complexe. Cela exige une connaissance approfondie des tests, du fonctionnement des API et de leurs différentes applications possibles par rapport aux scénarios utilisateurs. L'ajout de la sécurité complexifie encore davantage la tâche, car la couche API est plus profonde et plus technique que la couche UI », explique Arthur Hicken, évangéliste en chef chez Parasoft.
« Les tests d'API peuvent être étonnamment complexes. Lorsqu'on y ajoute la sécurité… la couche API est plus profonde et plus technique que la couche UI. »
—Arthur Hicken, responsable de l'évangélisation chez Parasoft
Test SOAtest de Parasoft Smart API Test Generator exploite un plugin de navigateur qui utilise l'IA pour convertir automatiquement les tests d'interface utilisateur manuels et automatisés en tests d'API automatisés. Au lieu de simplement collecter le trafic, de l'enregistrer et de le reproduire, Le générateur de tests d'API intelligent utilise l'IA Pour découvrir des tendances significatives, appliquer des modèles de menaces et comprendre les relations entre les appels d'API, il peut générer des scénarios de tests d'API automatisés qui reproduisent les actions de vos tests d'interface utilisateur, mais de manière entièrement automatisée et facilement extensible.
Prêt à plonger plus profondément ?
