Découvrez comment la solution Parasoft Continuous Quality permet de contrôler et de gérer les environnements de test pour fournir des logiciels de haute qualité en toute confiance. Inscrivez-vous pour la démo >>
Étant donné que les tests de pénétration sont coûteux et peuvent prendre beaucoup de temps à exécuter, nous devons effectuer des tests de sécurité des API de manière évolutive et durable.
Discuter de la sécurité des API et des raisons pour lesquelles nous devrions nous en soucier, c'est un peu comme parler de manger nos légumes. Nous savons tous que manger nos légumes est bon pour notre santé, mais combien d'entre nous le font réellement ? La sécurité des applications est un peu comme ça. Bien que cela soit essentiel pour la santé de nos applications et de nos entreprises, s'y efforcer n'est pas aussi intéressant que de créer de nouvelles fonctionnalités d'applications intéressantes. Mais il suffit de regarder les gros titres de l'actualité pour comprendre à quel point c'est important.
Traditionnellement, la validation d'une application ou d'une API pour la sécurité se faisait à la fin du processus de développement. Cependant, cela est intrinsèquement problématique. Il est généralement trop tard dans le processus pour corriger les erreurs découvertes: il peut être trop proche de la date de publication pour résoudre les problèmes, ou l'équipe peut être passée à d'autres projets, ou l'architecture de l'application peut être intrinsèquement non sécurisée.
De plus, les services et les applications d'aujourd'hui sont publiés plus souvent que jamais, souvent jusqu'à plusieurs fois par jour. Cette cadence de publication rapide rend l'approche traditionnelle intenable. Dans ce blog, je passerai en revue une étape par étape Liste de contrôle de la sécurité des API pour faire des tests de sécurité des API une partie automatisée du processus CI.
Pour résoudre ce problème, nous nous tournerons vers une solution que l'industrie utilise pour résoudre les problèmes de qualité logicielle avec des cycles de publication accélérés : l'intégration continue. L'intégration continue produit des builds chaque fois qu'un nouveau code est archivé et valide le nouveau code en exécutant une analyse statique et tests unitaires pour chaque build. Si les équipes sont sophistiquées, elles peuvent même créer et exécuter des tests fonctionnels automatisés à l'aide de CI (peut-être pas pour chaque version, car les tests fonctionnels prennent généralement beaucoup de temps à s'exécuter, mais au moins à des intervalles spécifiés comme une fois par jour).
Nous pouvons appliquer cette même solution aux tests de sécurité automatisés pour nos API en intégrant des tests de pénétration dans nos workflows CI. Cela garantira que nous testons les vulnérabilités de sécurité plus tôt, et cela nous donnera des tests de régression de sécurité qui peuvent détecter de nouveaux problèmes dès qu'ils sont introduits. Mais nous devrons être intelligents à ce sujet car les tests d'intrusion sont coûteux et peuvent prendre beaucoup de temps à exécuter. Nous devons le faire de manière évolutive et durable.
Je suppose que nos équipes sont déjà en train d'écrire et d'exécuter tests fonctionnels automatisés pour nos API. (Si nous ne le faisons pas, nous devons commencer ici et ne sommes pas prêts à envisager d'automatiser nos tests de sécurité.) Si nous exécutons des tests fonctionnels automatisés pour nos API, alors dans le cadre de nos processus de développement et d'assurance qualité normaux, nous pouvons identifier un sous-ensemble de ces tests fonctionnels à utiliser comme tests de sécurité. Nous préparerons et exécuterons ce sous-ensemble en tant que tests de sécurité.
Permettez-moi de décrire comment cela fonctionne en utilisant Parasoft SOAtest et son intégré tests de pénétration l'aide, qui est incluse dans le 2021.2 communiqué.
Pour commencer, supposons que nous ayons un scénario SOAtest avec 1 test de configuration qui nettoie la base de données et 3 tests qui effectuent 3 appels d'API différents. Nous souhaitons effectuer des tests d'intrusion pour chacune des 3 API appelées dans le scénario :
Nous allons d'abord préparer le scénario pour la sécurité en ajoutant un outil de test de pénétration à chacun des tests du scénario :
Nous exécuterons ensuite ce scénario à l'aide de SOAtest. Au fur et à mesure de l'exécution de chaque test, SOAtest effectuera l'appel d'API défini dans le test et capturera le trafic de requête et de réponse. L'outil de test de pénétration sur chaque test transmettra les données de trafic à une instance intégrée de l'outil de test de pénétration OWASP ZAP, qui effectuera des tests de pénétration sur l'API en fonction des paramètres de l'API qu'il observe dans les données de trafic, en utilisant ses propres heuristiques.
L'outil de test de pénétration signalera ensuite toutes les erreurs trouvées associées au test qui a accédé à l'API. Voici un exemple de rapport SOAtest avec toutes les erreurs organisées par CWE et par gravité :
Les résultats de SOAtest peuvent ensuite être rapportés dans DTP, le tableau de bord de reporting et d'analyse de Parasoft, pour des capacités de reporting supplémentaires. Voici une représentation de la façon dont cela fonctionne :
La réutilisation des tests fonctionnels pour les utiliser comme tests de sécurité offre les avantages suivants:
Il y a quelques éléments à prendre en compte lors de la réutilisation des tests fonctionnels pour les utiliser comme tests de pénétration:
Nous devons déterminer si nous devons exécuter nos tests fonctionnels et de sécurité dans le même environnement de test ou dans un autre. La réinitialisation de l'environnement entre les exécutions de tests fonctionnels et de sécurité, ou l'utilisation d'un environnement séparé, favorise une meilleure stabilité des tests, mais n'est généralement pas nécessaire. Nous pouvons souvent réutiliser le même environnement, mais lorsque nous le faisons, nous devons exécuter les tests fonctionnels en premier et les tests de sécurité en dernier, car les tests de sécurité peuvent déstabiliser l'environnement pour les tests fonctionnels. Lorsque nous utilisons différents environnements, nous devons nous assurer que nous configurons les scénarios de test fonctionnel d'origine avec des variables afin qu'il soit facile de pointer les tests vers différents points de terminaison pour différents environnements. SOAtest prend en charge cela à l'aide de variables d'environnement.
Nos API peuvent également dépendre d'autres API hors de notre contrôle. On peut envisager d'utiliser la virtualisation des services pour isoler notre environnement nous ne dépendons donc pas de ces systèmes externes. Cela aidera à stabiliser nos tests tout en évitant les conséquences involontaires sur les systèmes externes en raison de nos efforts de tests d'intrusion.
Nous pouvons garantir une meilleure qualité de nos API en déplaçant les tests de sécurité vers le développement et l'assurance qualité dans le cadre d'un processus automatisé. Nous pouvons tirer parti de nos tests fonctionnels API existants pour créer des tests de sécurité automatisés, qui nous permettront de découvrir et de corriger les erreurs de sécurité plus tôt dans le processus. Et j'espère que cela nous aidera à ne pas devenir l'un des prochains gros titres de l'actualité.
Nathan est directeur du développement chez Parasoft. Lui et ses équipes développent des capacités produit dans les domaines des tests d'interface utilisateur (Selenic), des tests d'API (SOAtest), de la virtualisation des services (Virtualize) et des tests unitaires (Jtest). Il travaille chez Parasoft depuis 2000.