Le test en boîte noire est une pratique clé dans les tests de logiciels et de sécurité, utilisés non seulement pour vérifier qu’une application fonctionne comme prévu, mais également pour limiter la surface d’attaque exposée aux acteurs malveillants. Découvrez pourquoi la combinaison de tests manuels en boîte noire avec des outils DAST automatisés est le moyen le plus efficace de garantir la sécurité des applications.
Restez à jour sur les tendances de la sécurité Web
Vos informations resteront privées .
Points clés à retenir
- Les tests de sécurité en boîte noire valident le comportement d’une application et vérifient qu’elle ne donne pas involontairement des points d’entrée à des pirates malveillants.
- Il s’appuie sur le test de l’application sans connaître son fonctionnement interne, imitant ainsi les actions des utilisateurs légitimes et des mauvais acteurs.
- Lorsqu’il est combiné avec DAST, le test manuel de la boîte noire pour les vulnérabilités est un moyen efficace de sécuriser les applications Web contre de nombreuses menaces.
Le test de la boîte noire est une méthodologie de test bien établie utilisée par les équipes informatiques pour vérifier qu’une application fonctionne comme elle est censée le faire, sans aucune connaissance de son code source ou des détails de sa configuration. De cette façon, l’application elle-même est la boîte noire, avec des testeurs fouillant dans l’inconnu. Les tests de boîte noire jouent également un rôle de premier plan dans l’identification des problèmes de sécurité.
Pour effectuer des tests en boîte noire, une équipe de test étudie d’abord les exigences et les documents de conception d’une application, puis crée une série de tests pour s’assurer que l’application est conforme. Supposons qu’une application bancaire en ligne soit conçue pour émettre un avertissement à un titulaire de compte lorsqu’une transaction par carte de débit est effectuée au-delà d’une limite prédéfinie. Les testeurs de la boîte noire écriraient un test pour créer une transaction qui dépasse la limite, puis vérifieraient qu’une alerte est envoyée au titulaire du compte communiquant les informations correctes.
Des milliers de scénarios de ce type sont écrits et exécutés pour tester des applications complexes. Un bon test de boîte noire utilise des données valides pour évaluer chaque action et option attendues sur l’écran d’un utilisateur, et vérifie soigneusement les résultats attendus. Ce type de test boîte noire est connu sous le nom de test positif.
Test en boîte noire pour la sécurité
Mais que se passe-t-il lorsqu’une application rencontre des données non valides ou une situation inattendue ? En utilisant notre exemple d’application bancaire, que se passe-t-il si un client entre une transaction de débit pour 0,00 € ? Les testeurs voudront voir si l’application sait comment gérer la situation et quel type de condition d’erreur en résulte. Par exemple, l’application va-t-elle planter ? Entrez les tests négatifs.
Les tests négatifs sont particulièrement utiles à des fins de sécurité, car ils émulent la vision d’un pirate informatique de l’application comme une boîte noire avec des points d’entrée vulnérables à trouver et à attaquer. La combinaison des tests manuels de boîte noire avec les tests dynamiques de sécurité des applications (DAST) , qui analysent les applications Web en cours d’exécution à la recherche de vecteurs d’attaque, puis exécutent des tests automatisés, fournit un outil puissant aux équipes informatiques lorsqu’elles déploient de nouvelles applications sécurisées et stables. . Étant donné que les outils DAST peuvent inclure des milliers de contrôles de sécurité intégrés, ils peuvent faire gagner beaucoup de temps par rapport à la définition et à l’exécution de tests purement manuels tout en comblant les lacunes dans les étendues de test.
Une partie des tests négatifs consiste à s’assurer qu’en cas de données invalides, un message d’erreur est émis qui est utile à l’utilisateur mais ne trahit rien sur les composants internes de l’application, car ces informations peuvent être très utiles aux attaquants.
Les messages d’erreur par défaut peuvent inclure des traces de pile qui s’exécutent sur des centaines de lignes, résumant le logiciel de la pile qui est actif au moment où l’erreur s’est produite. Ces informations sont destinées à être une ressource de diagnostic pour aider les développeurs à localiser et à résoudre un problème. Par exemple, cet extrait de 135 lignes de données d’erreur d’une application Java hébergée sur un serveur, récemment publié par un universitaire, identifie que le système s’exécute sur Java et utilise le framework Struts exécuté dans un conteneur Java EE (édition entreprise).
Ces détails sont comme une feuille de route pour un pirate, et notez que des messages d’erreur aussi étendus ne sont pas uniques à Java – le framework .NET de Microsoft peut fournir des informations de pile tout aussi détaillées. Dans ce cas, l’utilisation du framework Struts serait une information particulièrement utile. Struts a eu sa part de failles de sécurité qu’un pirate informatique préparé peut rechercher et sonder pour voir si une organisation a ignoré des correctifs ou des mises à jour, facilitant par inadvertance l’entrée dans son système.
Ce n’est pas qu’un exemple vain. Les pratiques de patching laxistes ont été la cause d’une effraction majeure au bureau de crédit d’Equifax en septembre 2017, lorsqu’une implémentation Struts non corrigée a permis une attaque par injection de commande qui a exposé les données de 143 millions de personnes.
Poursuivant avec l’exemple des messages d’erreur trop verbeux, les tests de boîte noire tentent de vérifier que, quelle que soit l’erreur, les informations internes sur le système ne sont pas révélées. Un message d’erreur approprié indiquerait simplement qu’une erreur s’est produite et qu’une action ne peut pas continuer. Il peut également demander à l’utilisateur de vérifier sa demande et de réessayer ou de fournir d’autres instructions utiles.
Dans ce cas, compléter les tests de boîte noire avec DAST offrirait deux avantages clés : les tests manuels auraient révélé que les messages d’erreur exposaient des informations cruciales aux attaquants, tandis que DAST aurait identifié l’implémentation Struts non corrigée.
Tests boîte noire et SDLC
Les tests d’application dans le cycle de vie du développement logiciel (SDLC) se divisent en deux catégories générales : les tests en boîte blanche et, comme nous l’avons vu jusqu’à présent, les tests en boîte noire.
Les tests en boîte blanche dépendent de la connaissance du code du système. Il comprend toutes les vérifications effectuées par les développeurs, telles que les tests unitaires et les tests d’intégration, ainsi que de nombreux tests effectués par les ingénieurs de test, tels que certains types de tests de régression. Les outils d’analyse statique (SAST) entrent également dans cette catégorie. Tous ces tests occupent des places connues et établies dans le SDLC, dans le but de préparer une application pour les tests fonctionnels. Dans les étapes ultérieures, ces tests peuvent également être complétés par des tests automatisés en boîte noire avec DAST, qui teste les API et de nombreuses autres facettes des applications Web pour révéler des vecteurs d’attaque supplémentaires.
Les tests fonctionnels comportent deux composants principaux : les tests de boîte noire et les tests d’acceptation par l’utilisateur (UAT). Le moment où ces tests sont effectués varie considérablement en fonction de l’organisation informatique et du type de SDLC qu’elle utilise. Par exemple, une organisation qui pratique le développement agile peut effectuer fréquemment des tests UAT, mais des tests formels en boîte noire plus tard dans le SLDC et moins fréquemment. Pendant ce temps, une organisation avec des exigences étendues et une conception considérable à l’avance peut effectuer des tests de boîte noire avant de lancer un cycle d’UAT.
L’un des avantages des tests en boîte noire par rapport à leur place dans le SDLC est que le travail de conception des tests peut commencer dès le moment où les exigences ont été finalisées.
Une autre pratique de test, le développement piloté par le comportement (BDD) , exploite les tests boîte blanche et boîte noire pour exécuter des tests fonctionnels. BDD vise à spécifier le comportement détaillé de l’application à l’avance sous une forme qui peut être exécutée par les développeurs dans le cadre de leurs tests de routine. Dans BDD, les tests sont généralement spécifiés par les utilisateurs et les parties prenantes à l’aide d’un lexique spécial que les outils BDD traduisent en tests de développement. En utilisant BDD, les développeurs et les parties prenantes peuvent être sûrs qu’au moment où une application est prête pour les tests de boîte noire et les UAT, elle remplit déjà la plupart, sinon la totalité, de ses exigences connues.
Limites des tests en boîte noire
Les tests en boîte noire sont une exigence pour la plupart des organisations qui peuvent prendre en charge une équipe distincte de testeurs de logiciels. Parce que ces testeurs travaillent à partir de scripts spécifiques, ils ont une connaissance complète de ce qu’ils ont testé. En cas de test positif, il est possible de savoir que le produit a été testé de manière exhaustive.
Cependant, les tests négatifs n’offrent pas de telles garanties, en particulier en matière de sécurité. Les pirates sont extrêmement créatifs pour trouver de petites vulnérabilités inattendues qui ont échappé à l’attention des concepteurs d’applications ; ils ne sont pas testés parce qu’ils ne sont tout simplement pas connus. Les tests en boîte noire peuvent révéler des problèmes inconnus, mais ne peuvent jamais affirmer que toutes les vulnérabilités possibles ont été découvertes.
Les systèmes comportant de nombreuses pièces mobiles, telles que les applications Web d’entreprise ou les configurations de l’Internet des objets, sont particulièrement difficiles à couvrir de manière exhaustive avec des tests de boîte noire négatifs. Par conséquent, les organisations informatiques soucieuses de la sécurité complètent les tests manuels de la boîte noire par plusieurs formes de tests dynamiques, en particulier DAST. Cette forme de test automatisé vérifie les vulnérabilités dans les applications en cours d’exécution que les tests de boîte noire pourraient ne pas détecter, et il vérifie également les systèmes par rapport aux vulnérabilités des produits nouvellement publiées au fur et à mesure qu’elles deviennent connues.
Comme pour tout ce qui concerne la sécurité, la meilleure approche implique plusieurs formes de test et de surveillance qui se chevauchent, dont le test de la boîte noire est un élément central.
