3 méthodes de Tests d'intrusion

Tests en boîte noire, grise ou blanche : quelles différences ?

Sommaire

Lorsqu’un logiciel ou une application sont créés, il est vital de réaliser plusieurs types de tests pour s’assurer que le produit est fini, complet, sécurisé et efficace. Pour réaliser ces tests, plusieurs méthodes sont possibles : les tests en « boîte noire », en « boîte blanche » et en « boîte grise ». Chacune de ces méthodes offre des possibilités différentes, que nous allons exposer dans cet article.

Les tests en « boîte noire »

Les tests en « boite noire » consistent à examiner uniquement les fonctionnalités d’une application, c’est-à-dire si elle fait ce qu’elle est censée faire, peu importe comment elle le fait. Sa structure et son fonctionnement interne ne sont pas étudiés. Le testeur doit donc savoir quel est le rôle du système et de ses fonctionnalités, mais ignore ses mécanismes internes. Il a un profil uniquement « utilisateur ».

Ainsi, cette méthode sert à vérifier, après la finalisation d’un projet, si un logiciel ou une application fonctionne bien et sert efficacement ses utilisateurs. En général, les testeurs sont à la recherche de fonctions incorrectes ou manquantes, d’erreurs d’interface, de performance, d’initialisation et de fin de programme, ou bien encore d’erreurs dans les structures de données ou d’accès aux bases de données externes.

Pour cela, ils préparent des scénarios calqués sur les différents chemins utilisateur possibles sur le système testé. Toutes les fonctionnalités doivent être prises en compte, pour qu’une fois tous les tests effectués, elles aient toutes été éprouvées. Les tests consistent à suivre un scenario, et à vérifier pour chaque fonctionnalité que les entrées (inputs) valides sont acceptées, que celles non valides sont refusées, et bien entendu, qu’à chaque fois, le résultat (sortie ou output) attendu est bien obtenu. C’est ce que l’on appelle la méthode « trial and error » (essais et erreurs).

Les avantages de cette méthode sont les suivants :

Mais les tests en « boîte noire » ont également des inconvénients :

Dans le cas des tests d’intrusion

Dans le cas particulier des tests d’intrusion, le principe reste le même : les testeurs ne connaissent rien sur le fonctionnement de l’application, et ils n’ont pas accès à son code source. Ils se retrouvent donc dans la peau d’un internaute normal : c’est en général l’état dans lequel se trouvent les pirates, ce qui rend ces tests très réalistes. Cependant, des connaissances en programmation sont dans ce cas utiles, voire nécessaires, pour le testeur (comme pour un pirate), car elles vont l’aider à identifier les tests pertinents à réaliser.

Cependant, les tests d’intrusion en boîte noire peuvent prendre beaucoup de temps (les testeurs vont vérifier de nombreuses méthodes d’attaques différentes pour s’assurer qu’aucune ne fonctionne). De plus, comme précisé plus haut, certaines parties de l’infrastructure du système ne seront pas testées, car elles n’ont aucune influence sur l’interface utilisateur sur laquelle le test a lieu.

Les tests en « boîte blanche »

Les tests en « boîte blanche » consistent à examiner le fonctionnement d’une application et sa structure interne, ses processus, plutôt que ses fonctionnalités. Sont ici testés l’ensemble des composants internes du logiciel ou de l’application, par l’intermédiaire du code source, principale base de travail du testeur.

Pour réaliser un test en « boîte blanche », ce dernier doit donc avoir des compétences de programmation, afin de comprendre le code qu’il étudie. Il doit également avoir une vue globale du fonctionnement de l’application, des éléments qui la composent, et naturellement de son code source. Contrairement aux tests en « boîte noire », le testeur ici a un profil développeur, et non pas utilisateur.

En effectuant un test en « boîte blanche », on voit en effet quelle ligne de code est appelée pour chaque fonctionnalité. Cela permet de tester le flux de données ainsi que la gestion des exceptions et des erreurs. On s’intéresse également à la dépendance des ressources, ainsi qu’à la logique interne et justesse du code. C’est pourquoi ces tests sont surtout utiles pendant le développement d’une application, même s’ils peuvent être effectués durant de nombreuses phases de la vie d’un projet. La méthode en « boîte blanche » peut être appliquée pour les tests unitaires (majoritairement), les tests d’intégration et les tests système.

La méthode en « boîte blanche » utilise des scénarios de test, créés par le testeur selon ce qu’il a appris du code source de l’environnement. L’objectif est qu’en testant l’ensemble de ces scénarios, toutes les lignes de code soient vérifiées. Ce qui est regardé, c’est le processus effectué par l’application après une entrée (input) pour obtenir un résultat. On ne fait que vérifier si le code produit les résultats espérés.

Cette méthode a plusieurs avantages :

Mais on ne peut pas tout avoir… C’est pourquoi ces tests ont également des inconvénients.

Dans le cas des tests de pénétration

Si cette méthode est utilisée dans le cadre d’un test de pénétration, cela signifie que les testeurs connaissent le fonctionnement du système attaqué : ils ont accès au code source, au design de l’architecture de l’application… Les testeurs se basent alors sur ces connaissances pour élaborer des tests permettant de vérifier la sécurité de l’application.

Cela permet notamment, par rapport à la méthode en « boîte noire », de tester la qualité de code, et d’avoir un champ d’action beaucoup plus étendu. Cependant, cette méthode ne permet pas de tester l’application en conditions « réelles », car aucun pirate n’aurait accès à autant d’information ; elle permet pourtant de sécuriser efficacement son application, notamment contre les menaces internes !

Les tests en « boîte grise »

Les tests en « boîte grise » compilent ces deux précédentes approches : ils éprouvent à la fois les fonctionnalités et le fonctionnement d’un système. C’est-à-dire qu’un testeur va par exemple donner une entrée (input) à un système, vérifier que la sortie obtenue est celle attendue, et vérifier par quel processus ce résultat a été obtenu.

Dans ce type de tests, le testeur connaît le rôle du système et de ses fonctionnalités, et a également une connaissance, bien que relativement limitée, de ses mécanismes internes (en particulier la structure des données internes et les algorithmes utilisés). Attention cependant, il n’a pas accès au code source !

Ces tests peuvent difficilement être effectués pendant la phase de développement du projet, car elle implique des tests sur les fonctionnalités du programme : celui-ci doit déjà être dans un état proche de final pour que ces tests puissent être pertinents. En effet, pendant les tests en « boîte grise », ce sont surtout des techniques de « boîte noire » qui sont utilisées, puisque le code n’est pas accessible. Cependant, les scénarios sont orientés pour jouer sur les processus sous-jacents, et ainsi les tester également.

Bien entendu, la méthode « boîte grise » combine surtout les avantages des méthodes « boîte blanche » et « boîte noire ». On peut cependant noter deux gros bénéfices de cette technique :

En parallèle, l’un des inconvénients les plus importants de ces tests est le suivant :


Dans le cas des tests de pénétration

Dans le cas des tests de pénétration, la méthode « boîte grise » consiste à effectuer les tests en étant logué sur l’application avec un compte utilisateur. C’est un niveau intermédiaire, où les testeurs connaissent les mécanismes internes de l’application, et qui les oriente dans leurs choix de tests. Il permet de créer des tests relativement exhaustifs, tout en les maintenant dans une optique relativement réaliste et proche de ce que pourrait faire un réel pirate.

Pour mieux comprendre…

Une analogie est souvent utilisée pour différencier ces techniques, en comparant le système testé à une voiture.

  • En méthode « boîte noire », on vérifie que la voiture fonctionne en allumant les lumières, en klaxonnant et en tournant la clé pour que le moteur s’allume. Si tout se passe comme prévu, la voiture fonctionne.
  • En méthode « boîte blanche », on emmène la voiture chez le garagiste, qui regarde le moteur ainsi que toutes les autres parties (mécaniques comme électriques) de la voiture. Si elle est en bon état, elle fonctionne.
  • En méthode « boîte grise », on emmène la voiture chez le garagiste, et en tournant la clé dans la serrure, on vérifie que le moteur s’allume, et le garagiste observe en même temps le moteur pour s’assurer qu’il démarre bien selon le bon processus.

Vous souhaitez faire appel à nos équipes ? Contactez-nous !

Vous souhaitez solliciter notre expertise en Tests d'intrusion ?

3 méthodes de Tests d'intrusion
Autres articles
CRAM : Cas client Pentest Externe et Interne

CRAM : Cas…

Un Cas Client sur comment renforcer son SI grâce au pentest (Test d’intrusion) Découvrez dans…

Un Livre Blanc sur le contournement des EDR et antivirus

Un Livre Blanc…

Les failles des EDR et antivirus exposées Les EDR (Endpoint Detection and Response) et les…

Chef de projet : un rôle clé pour la réussite des missions NBS System

Chef de projet…

Quel est le rôle d’un chef de projet  Cybersécurité ? Être chef de projet au…

Retour en haut
Aller au contenu principal