Les bases des tests en boîte noire
Simuler des attaques lors des tests de sécurité
Écrit par
0 minutes de lecture
Le test en boîte noire expliqué
Créer des applications à la fois de grande qualité et sécurisées est l’un des principaux défis du développement logiciel. Les tests de sécurité permettent de relever ces deux défis en identifiant les failles et les vulnérabilités potentielles des logiciels. Le test en boîte noire constitue un bon point de départ, car il simule la façon dont un attaquant exploiterait les failles d’un système pour y accéder.
Dans cet article, nous abordons tout ce qu’il faut savoir sur les tests en boîte noire, notamment leurs types et leurs techniques.
Qu’est-ce que le test en boîte noire ?
Le test en boîte noire est une méthode de test logiciel qui ne nécessite pas de connaître la façon dont une application est conçue. Il s’appuie sur un large éventail de techniques pour détecter les vulnérabilités ou les faiblesses d’un produit, en simulant la manière dont un attaquant réel chercherait des failles exploitables dans le logiciel.
Diagramme de test en boîte noire
4 types de tests en boîte noire
Les professionnels de la sécurité s’appuient sur différentes techniques de test en boîte noire, automatisées ou manuelles, pour évaluer la sécurité d’un système. Passons en revue quelques-uns des types de tests en boîte noire les plus courants.
1. Analyse des vulnérabilités
Pour pirater une application, un attaquant doit d’abord comprendre son fonctionnement. L’analyse des vulnérabilités permet facilement aux pirates de se renseigner sur un système et d’en repérer les failles. Mais elle joue aussi un rôle important dans la sécurité des applications, car elle vous permet d’adopter le point de vue d’un pirate pour prévenir ce type d’attaque.
Les outils automatisés de test en boîte noire, comme ZAP, détectent souvent les vulnérabilités les plus faciles à repérer. Les professionnels de la sécurité plus expérimentés peuvent compléter ces outils par des tests manuels pour découvrir les vulnérabilités qui auraient échappé aux tests automatisés. Vous pouvez également combiner plusieurs outils pour rechercher des vulnérabilités, par exemple les outils pris en charge dans Kali Linux ou les Chrome DevTools pour inspecter des applications Web.
2. Tests d’intrusion
Les tests d’intrusion simulent des scénarios d’attaque réels dans lesquels des pirates tentent d’accéder à des données et de les collecter afin de compromettre le système et de mener des actions malveillantes.
Les tests d’intrusion sont généralement effectués manuellement, en fonction de l’expérience du testeur. Par exemple, ils peuvent servir à vérifier l’API qui récupère la liste des produits disponibles à l’achat. Il faut alors la tester avec différentes entrées pour détecter d’éventuelles réponses anormales ou l’affichage d’erreurs de trace de pile.
Les tests d’intrusion peuvent également être automatisés à l’aide d’outils open source comme Powershell Suite.
3. Découverte de la topologie du réseau
La découverte de la topologie du réseau permet de comprendre l’organisation actuelle du réseau au sein de votre système, notamment les liens entre ses différents éléments et leurs interactions. Cela aide à repérer les éléments potentiellement vulnérables du réseau afin d’atténuer les risques.
4. Évaluation des risques
Ce type particulier de test de sécurité requiert très peu de connaissances techniques sur le système et porte davantage sur les aspects métier : les exigences susceptibles de présenter des risques pour la sécurité. L’évaluation des risques peut être menée dès les premières étapes du développement d’un produit, de sa conception à la planification des sprints de l’équipe de développement logiciel. Elle permet ainsi de prévenir les problèmes de sécurité en amont du SDLC.
Lancez-vous dans les compétitions Capture The Flag
Apprenez à résoudre des défis Capture The Flag en regardant à la demande notre atelier virtuel d’initiation.
Exemple de test en boîte noire
Prenons un exemple de test en boîte noire.
Commencez par cloner ce dépôt dans votre environnement local : https://github.com/appsecco/dvna. L’application exemple sera alors lancée. Elle comporte plusieurs failles exploitables :
Pour configurer rapidement l’exemple, exécutez la commande suivante :
Analyse automatisée des vulnérabilités avec ZAP
Nous allons utiliser ZAP pour effectuer des tests en boîte noire. Vous devez donc installer ZAP sur votre machine.
Commençons par lancer des analyses automatisées pour rechercher des vulnérabilités sur le site. Une fois l’analyse terminée, vous disposerez d’une liste d’alertes accompagnées d’une description et d’une solution proposée pour chacune.
Injection SQL manuelle
L’analyse automatisée est simple à réaliser et constitue un bon point de départ pour les tests de sécurité, mais certains aspects doivent être testés manuellement. L’injection SQL en est un exemple. Exécutons la requête SQL simple ' or '1'='1 pour lancer une recherche dans l’application :
On voit ici que l’interface affichée à tous les utilisateurs du système a été affectée. Des pirates pourraient ainsi collecter les données des utilisateurs, voire vendre les données des clients à des entreprises concurrentes.
Le processus de test en boîte noire
Le test en boîte noire recherche les problèmes de sécurité exploitables dans les systèmes, sans qu’il soit nécessaire d’accéder au code du produit logiciel ou de comprendre en détail comment l’application est développée. Une fois le test terminé, il fournit une liste de bogues de sécurité à examiner, à hiérarchiser et à corriger.
Les étapes suivantes sont les suivantes :
L’équipe de développement doit trouver une solution à chaque problème de sécurité.
Les analystes de sécurité vérifient une nouvelle fois que les bogues ont bien été corrigés.
L’équipe de développement exécute des tests de régression pour vérifier que tout fonctionne et que la correction n’a pas endommagé de fonctionnalités existantes.
4 techniques de test en boîte noire
Les tests de sécurité peuvent être considérés comme un art, surtout lorsqu’il s’agit de tests en boîte noire. La règle fondamentale consiste à faire preuve de créativité et à penser comme un pirate. Il existe plusieurs techniques de test en boîte noire.
1. Fuzzing
Le fuzzing consiste à tester des services d’API ou des interfaces Web en observant le comportement du système face à des entrées aléatoires ou personnalisées. Si un comportement inhabituel est détecté, l’équipe de développement doit en trouver la cause profonde et apporter une correction.
2. Tests syntaxiques
Les tests syntaxiques recherchent les entrées non valides, par exemple une syntaxe incorrecte. Ils vérifient également si le système expose des données sensibles liées aux bases de données ou aux informations client, que des pirates pourraient exploiter.
3. Tests exploratoires
Les tests exploratoires sont une technique courante d’analyse en boîte noire qui permet aux analystes de sécurité de mieux comprendre le système en recherchant des problèmes de sécurité cachés tout au long du processus de test. Les bogues de sécurité sont repérés et signalés au fil de l’analyse, avec des corrections suggérées.
4. Analyse des données
Les tests d’analyse des données consistent à examiner les journaux, les réponses des services backend d’API ou les interfaces Web susceptibles d’être illicites ou de servir à attaquer le système ou à collecter les données des utilisateurs. Pour effectuer ces tests correctement et efficacement, il faut disposer d’un système performant de surveillance et de débogage permettant de collecter les journaux et de visualiser les données. Il peut également être nécessaire de configurer des règles d’alerte de sécurité pour être immédiatement informé de tout problème.
Tests en boîte noire et en boîte blanche
Certains tests de sécurité nécessitent de combiner les tests en boîte noire et les tests en boîte blanche. Examinons les différences entre deux des méthodes de test en boîte noire et en boîte blanche les plus répandues : les tests de sécurité des applications dynamiques (DAST) et les tests de sécurité statiques des applications (SAST).
Méthode en boîte noire : tests de sécurité des applications dynamiques (DAST)
Tests dynamiques réalisés sans accéder au code source de l’application ni l’analyser.
Peuvent être effectués manuellement (par des experts en sécurité) ou automatiquement.
L’application est testée de l’extérieur, sans accéder à sa structure interne.
Il est difficile de vérifier que l’ensemble de la base de code a été couvert.
Le coût est généralement plus élevé, car l’application doit être déployée pour être testée.
Méthode en boîte blanche : tests de sécurité statiques des applications (SAST)
SAST sert à analyser le code source.
Les tests sont généralement exécutés avant la compilation du code.
Ils sont souvent réalisés à l’aide d’outils SAST automatisés.
Ils peuvent analyser 100 % de la base de code.
Les problèmes de sécurité coûtent moins cher à corriger, car ils sont détectés plus tôt dans le cycle de vie du développement logiciel.
Le choix entre les tests en boîte noire, en boîte blanche ou une combinaison des deux dépend de votre cas d’usage.
Lancez-vous dans les compétitions Capture The Flag
Apprenez à résoudre des défis Capture The Flag en regardant à la demande notre atelier virtuel d’initiation.
Conclusion
Les tests en boîte noire jouent un rôle important dans la sécurité des applications. Sans connaissance de l’architecture interne du logiciel, cette méthode de test offre une vision objective de votre application, dans des conditions proches du réel. Même s’ils ne couvrent pas l’ensemble de la base de code, associés à d’autres méthodes de test de sécurité, ils permettent aux équipes de sécurité de livrer des produits de grande qualité et plus sûrs.
Avec des outils conçus pour les développeurs et une intelligence de sécurité de pointe, Snyk aide les développeurs à livrer plus rapidement des produits de qualité, tout en sécurisant leur code, leurs bibliothèques open source, leurs conteneurs et leur infrastructure as code. Réservez une démo dès aujourd’hui.