La méthodologie de test web : OWASP WSTG et grandes étapes

Dans le cours précédent, vous avez appris comment fonctionnent les réseaux, Linux et la cryptographie, et vous avez posé les bases du cadre légal d’un test d’intrusion. Il est temps de les appliquer à l’univers qui concentre la majorité des incidents : les applications web. Avant de toucher le moindre outil, cette première leçon vous donne la carte et la boussole : une méthode de travail, et les règles du jeu.

Pourquoi une méthodologie ?

Imaginez un médecin qui, face à un patient, prescrirait des examens au hasard. Il passerait peut-être à côté de l’essentiel, et il ne pourrait pas expliquer ce qu’il a vérifié. Le test d’intrusion web obéit à la même logique : sans méthode, on teste ce qu’on connaît déjà, on oublie des zones entières de l’application, et on est incapable de dire au client ce qui a été couvert.

Une méthodologie apporte trois choses :

• De l’exhaustivité : une liste de contrôles à parcourir permet de ne rien omettre.
• De la reproductibilité : une autre personne peut refaire le même test et obtenir le même résultat.
• De la preuve : on peut démontrer ce qui a été examiné, y compris quand on n’a rien trouvé.

L’OWASP et son guide de test

L’OWASP (Open Worldwide Application Security Project) est une communauté ouverte qui publie gratuitement des références sur la sécurité des applications. Deux documents sont à distinguer, car on les confond souvent :

• Le Top 10 est une liste de sensibilisation : les grandes catégories de risques les plus courantes dans les applications web. C’est un point de départ pour parler des risques, pas un plan de test.
• Le WSTG (Web Security Testing Guide) est le guide de test : il décrit, catégorie par catégorie, quoi vérifier et comment le vérifier. C’est lui qui sert de colonne vertébrale à un audit.

Vous pouvez consulter ces ressources sur owasp.org. Elles évoluent régulièrement : référez-vous toujours à la version en ligne la plus récente plutôt qu’à un souvenir.

Les grandes étapes d’un test web

Le WSTG range les contrôles en familles. Sans les recopier, voici comment on peut les regrouper en étapes logiques, qui correspondent aussi aux chapitres de ce cours :

Le cycle de travail d’un testeur

Quelle que soit la famille de contrôles, le geste est toujours le même, en quatre temps :

1. Observer : comprendre comment la fonctionnalité marche en usage normal.
2. Formuler une hypothèse : « et si ce paramètre n’était pas vérifié côté serveur ? »
3. Tester avec mesure : une expérience minimale, qui prouve le problème sans rien casser.
4. Consigner : noter ce qu’on a fait, ce qu’on a vu, et pourquoi c’est un problème.

Le troisième temps mérite une insistance : un bon testeur prouve l’existence d’une faille avec la preuve la plus petite possible. Il ne cherche pas à « aller le plus loin possible », ce qui n’est pas son travail et peut causer des dégâts.

Les règles d’engagement

En mission réelle, un document précise ce qui est permis : les adresses et applications incluses (le périmètre), les techniques autorisées ou exclues, les horaires, la personne à prévenir en cas de problème. Ces règles d’engagement protègent à la fois le client et le testeur. Dans notre cadre d’entraînement, nous nous les imposons aussi, par discipline. Vous les écrirez dans un instant, dans votre carnet.

Votre fil rouge : le carnet de test

Tout au long du cours, vous allez auditer pas à pas une application d’entraînement légale et consigner chaque constat dans un carnet de test. Il vous suivra jusqu’au rapport final du chapitre 7. Voici le modèle d’une entrée, à reproduire dans un simple fichier texte ou un tableur :

Constat n° : 01
Date / heure :
Application / version d’entraînement :
Page ou fonction concernée :
Paramètre ou élément testé :
Ce que j’ai fait (étapes) :
Ce que j’ai observé :
Pourquoi c’est un problème :
Preuve (capture, extrait de réponse) :
Gravité estimée (faible / moyenne / élevée / critique) :
Correction suggérée :

Cette discipline paraît fastidieuse au début. Elle devient vite un réflexe, et c’est elle qui distingue un professionnel d’un amateur.

À vous de jouer

Créez le fichier de votre carnet et rédigez la première page : l’en-tête de mission. Il doit contenir :

• l’environnement d’entraînement que vous allez utiliser (vous le choisirez dans la leçon 3, notez pour l’instant « à définir ») ;
• une phrase de périmètre : ce que vous avez le droit de tester ;
• trois règles que vous vous engagez à respecter.

CARNET DE TEST - Audit d’une application d’entraînement
Environnement : à définir (laboratoire personnel, hors Internet)
Périmètre : uniquement l’application d’entraînement installée sur ma machine
virtuelle ; aucune autre adresse, aucun autre site.
Règles :
1. Je ne teste que ce qui est dans le périmètre ci-dessus.
2. Je fais le test minimal qui prouve un problème, sans dégrader le service.
3. Je consigne chaque action et chaque constat dans ce carnet.

Dans la leçon suivante, vous allez découvrir l’outil central du testeur web : le proxy d’interception, qui permet de voir et de rejouer les échanges entre un navigateur et une application.