Test d'intrusion

Ce que couvre un test d'intrusion

Un test se définit par son périmètre, pas par ses outils. Sur une application web, le travail se répartit en général en six endroits, et un rapport qui en oublie un décrit un système plus petit que celui qui tourne en production.

• Authentification : comment les comptes sont créés, comment les sessions sont émises, et si la réinitialisation du mot de passe ou le second facteur peuvent être contournés.
• Habilitations : si un utilisateur, un rôle ou un client peut atteindre les données d'un autre en changeant un identifiant, un paramètre ou l'ordre d'une suite de requêtes.
• Traitement des entrées : injection dans les requêtes, les gabarits, les en-têtes et les chemins de fichiers, testée selon les catégories décrites dans l'OWASP Web Security Testing Guide.
• Logique métier : remises, quotas, étapes de validation et machines à états, là où le défaut est une séquence que le code autorise et que le métier n'autorise pas.
• Sessions et jetons : fixation, expiration, révocation, et ce qu'il advient d'une session déjà ouverte au moment du changement de mot de passe.
• Configuration et exposition : erreurs bavardes, points de debug, CORS permissif, en-têtes de sécurité absents et secrets laissés dans les bundles côté client.

Le périmètre se fixe par écrit. Deux applications de même taille peuvent demander des périmètres très différents, parce que ce qui pèse sur la charge de travail, c'est le nombre de portes d'entrée, pas le nombre de pages.

Ce qu'un test d'intrusion ne couvre pas

La plupart des malentendus sur un rapport viennent de ce qu'on n'a jamais demandé au test. Voici les cas habituels.

• Le déni de service et la charge : saturer un système en production mesure votre patience, pas sa sécurité, et cela relève d'une autre mission.
• La revue de code : un test en boîte noire voit le comportement. Il ne voit pas la branche que personne n'a déployée, ni la bibliothèque accessible seulement derrière un feature flag.
• L'ingénierie sociale et l'accès physique : hameçonnage, prétexte et entrée dans un bâtiment sont des exercices séparés, avec leur propre autorisation.
• La certification de conformité : un test produit des constats, pas une attestation. Aucun rapport ne rend à lui seul une organisation conforme à un référentiel.
• Tout ce qui sort du périmètre convenu : un hôte, une version d'API ou un environnement laissé hors du document de périmètre n'est pas testé, quoi que laisse entendre le rapport.

Un prestataire qui refuse de dire clairement ce qui sort du périmètre vous apprend quelque chose sur le rapport que vous vous apprêtez à payer.

Comment se déroule un test d'intrusion

L'ordre compte plus que l'outillage. Chaque phase produit quelque chose dont la suivante se sert, et sauter une phase, c'est transformer une évaluation en une liste de sorties de scanner sans preuve derrière.

1. 01Périmètre et règles d'engagement

   Hôtes, comptes, environnements, fenêtres de test, et la personne qui peut arrêter la mission en cours de route. Rien n'est touché avant que ce document existe : c'est ce qui sépare un test d'une intrusion.

2. 02Reconnaissance et cartographie

   L'auditeur cartographie ce que l'application expose : routes, paramètres, rôles, versions d'API, et les parties de la surface dont aucune documentation ne parle.

3. 03Modélisation des menaces et plan de test

   L'effort suit ce à quoi sert l'application. Un point de statut en lecture seule et un parcours de paiement ne portent pas le même risque, et un plan qui les traite pareil dépense le budget au mauvais endroit.

4. 04Tentatives d'exploitation

   Chaque hypothèse est éprouvée sur le système en fonctionnement. Une faiblesse soupçonnée reste un soupçon tant qu'elle ne produit pas un effet que l'auditeur peut démontrer, avec la requête et la réponse qui l'ont produit.

5. 05Rapport et contre-test

   Ce qui a été reproduit est écrit avec son impact dans votre contexte. Plus tard, un contre-test dit quels constats sont réellement clos, et c'est la seule partie qui reste utile une fois les correctifs livrés.

L'ordre des phases suit la structure du Web Security Testing Guide d'assez près pour que le rapport soit lisible par quiconque connaît ce document.

Combien de temps prend un test d'intrusion

La durée découle du périmètre, et quiconque annonce un chiffre avant d'avoir lu le périmètre devine. Ce qui la fait varier : le nombre de rôles et de clients distincts, la taille de la surface d'API, l'existence d'un environnement de recette qui reflète la production, le nombre de comptes de test que l'équipe peut créer, et la vitesse à laquelle le client répond aux questions pendant la fenêtre.

L'ordre praticable, c'est le périmètre d'abord, le calendrier ensuite. Un test raccourci pour tenir une date ne produit pas un résultat plus petit, il produit un résultat avec des trous inconnus. Quand un prestataire vous donne une date avant que vous ayez décrit l'application, la date est le livrable.

Ce que contient le rapport

Le rapport est un document de travail pour celui qui doit corriger, pas un certificat à ranger dans un tiroir.

• Un constat par problème vérifié, avec le point d'entrée, le paramètre et le compte avec lequel il a été atteint.
• Les étapes de reproduction : les requêtes, dans l'ordre, qui ont produit l'effet.
• L'impact dans votre contexte, c'est-à-dire la partie qu'un score de gravité ne peut pas fournir.
• Un score de gravité avec le référentiel nommé, pour que deux rapports se comparent honnêtement.
• Une direction de correction par constat, et son statut au contre-test une fois le correctif livré.

Ce que l'auditeur n'a pas pu reproduire va dans une annexe séparée avec sa raison, pas dans la liste des constats. Un soupçon déguisé en constat coûte à l'équipe le même temps qu'un vrai, et lui apprend à se méfier du rapport.

Qui le lit

• L'ingénierie lit les étapes de reproduction et le point d'entrée concerné.
• Le produit lit les constats de logique métier, qui correspondent rarement à une ligne de code.
• Celui qui tient le calendrier lit les vecteurs de gravité et le statut des contre-tests.
• La direction lit le résumé, et devrait être informée de ce que le test n'a pas couvert.

Comment les constats sont notés

Un score de gravité est une entrée de décision, pas la décision. Le CVSS mesure les propriétés techniques d'une faiblesse, comme le vecteur d'attaque, la complexité, les privilèges requis et l'impact, et il ne dit rien de la place de la fonctionnalité touchée : derrière un login, au contact de l'argent, ou désactivée depuis le trimestre dernier. Le même vecteur peut signifier une urgence différente dans deux entreprises. Le score est utile quand le rapport place le vecteur à côté du contexte métier, et trompeur quand il est présenté comme un verdict.

Lisez le vecteur, pas seulement le chiffre. Un score élevé sur une fonctionnalité que personne ne peut atteindre est une question de calendrier, et un score moyen sur le parcours de connexion n'en est pas une.

L'autorisation précède la première requête

Un test se déroule sur une autorisation écrite qui nomme la cible, les comptes, la fenêtre et la personne qui peut l'arrêter. C'est ce document qui distingue une évaluation d'une intrusion, et il protège l'auditeur autant que le client. Un prestataire qui accepte un feu vert oral, ou un périmètre qui inclut des systèmes que le client ne possède pas, ne rend pas service au client.

Sources

Chaque affirmation technique de cette page suit un document public. Aucun n'est le nôtre.

• OWASP Web Security Testing Guide — catégories de test et ordre dans lequel elles s'enchaînent
• OWASP Top 10 — les catégories de risque que les applications web partagent le plus souvent
• FIRST, spécification CVSS v4.0 — le référentiel de notation cité dans Comment les constats sont notés
• NVD, National Vulnerability Database — identifiants publics des vulnérabilités connues

Là où une phrase de cette page n'est adossée à aucun de ces documents, elle décrit notre façon de travailler, pas une règle du métier.