Comment faire des tests de sécurité des API une partie automatisée du processus CI

É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.

Entrez dans l'intégration continue

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.

Commencez par des tests fonctionnels

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:

1. Puisque nous écrivons déjà des tests fonctionnels, nous pouvons réutiliser le travail qui a déjà été fait, en économisant du temps et des efforts.
2. Pour exécuter certaines API, nous devrons peut-être effectuer une configuration, comme préparer la base de données ou appeler d'autres API. Si nous commençons avec des tests fonctionnels qui fonctionnent déjà, cette configuration est déjà terminée.
3. En règle générale, un outil de test de pénétration signalera qu'un certain appel d'API a une vulnérabilité, mais il ne donne aucun contexte sur le cas d'utilisation et / ou l'exigence auquel il est connecté. Puisque nous utilisons SOAtest pour exécuter les cas de test, les vulnérabilités de sécurité sont signalées dans le contexte d'un cas d'utilisation. Lorsque des scénarios ont été associés à des exigences, nous pouvons désormais obtenir un contexte commercial supplémentaire sur l'impact des erreurs de sécurité sur l'application.
4. Nous avons un scénario de test que nous pouvons utiliser pour reproduire facilement l'erreur ou pour valider qu'elle a été corrigée.

Préparation des tests fonctionnels à utiliser comme tests de sécurité

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:

1. Nous devons maintenir nos scénarios de test fonctionnel séparément de nos scénarios de test de sécurité et les exécuter à partir de tâches de test distinctes. La principale raison à cela est que l'ajout de tests d'intrusion aux tests fonctionnels existants servira probablement à déstabiliser les tests fonctionnels. Nous devons sélectionner les scénarios de tests fonctionnels qui doivent être transformés en tests de sécurité automatisés, puis faire des copies des tests fonctionnels qui seront conservés en tant que tests de sécurité distincts.
2. Nous devons être sélectifs dans les tests que nous choisissons car les tests de pénétration sont coûteux ; nous devons maximiser la surface d'attaque de l'API qui est couverte tout en minimisant le nombre de tests. Nous devrions considérer les éléments suivants :
   • Les outils de test de pénétration analysent le trafic de demande / réponse pour comprendre quels paramètres de la demande sont disponibles pour être testés. Nous devons sélectionner des tests fonctionnels qui exercent tous les paramètres de chaque API, pour nous assurer que chaque entrée de l'API est analysée.
   • Dans chaque scénario, nous devons décider quels appels d'API doivent faire l'objet d'un test d'intrusion. La même API peut être référencée à partir de plusieurs scénarios, et nous ne voulons pas dupliquer les tests d'intrusion sur une API testée dans un scénario différent. L'outil de test de pénétration ne doit être ajouté qu'aux tests appropriés pour les API à tester.
   • Le nombre de scénarios doit être gérable afin que le test de sécurité soit suffisamment court pour être exécuté au moins une fois par jour.

3. Nos scénarios de test fonctionnel peuvent avoir des sections de configuration ou de démontage pour l'initialisation ou le nettoyage. Ceux-ci n'ont généralement pas besoin d'être testés par pénétration.
4. Si le test fonctionnel a un quelconque paramétrage, nous devons le supprimer. Les outils de test d'intrusion n'ont pas besoin de plusieurs ensembles de valeurs pour les mêmes paramètres pour savoir quoi tester et l'envoi de différents ensembles de valeurs pourrait simplement allonger les tests en raison de tests en double.
5. Les tests fonctionnels de l'API auront généralement des assertions qui valident la réponse du service. Lorsqu'elles sont utilisées comme tests de sécurité, ces assertions peuvent échouer mais seront bruyantes lors de l'examen des résultats, car dans ce contexte, nous ne nous soucions que des vulnérabilités de sécurité trouvées. Nous devrions supprimer toutes les affirmations. Dans mon exemple précédent, cela signifierait supprimer l'asserteur JSON du test 3.
6. Certains appels d'API ajoutent des données à la base de données. Lors de l'utilisation d'un outil de test de pénétration contre de telles API, la base de données peut être surchargée d'informations en raison du nombre d'attaques que l'outil de test de pénétration dirige vers l'API. Dans certains cas, cela peut provoquer des effets secondaires inattendus. Dans l'une de nos équipes de développement, nous avons découvert un problème de performances dans l'application lorsqu'une API particulière ajoutait beaucoup de données en raison des attaques de test de pénétration. Les performances de l'application sont devenues si mauvaises qu'elles ont empêché le test de sécurité automatisé de se terminer dans un laps de temps raisonnable. Nous avons dû exclure les tests de sécurité pour cette API de notre exécution automatisée jusqu'à ce que nous ayons résolu le problème.

Maintenir un environnement de test stable

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.

Conclusion

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é.

Par Nathan Jakubiak

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.