Ma méthodologie.
Un test d'intrusion se juge autant sur son cadre que sur ses résultats. Ce qui suit décrit ce qui est fixé avant de commencer : sur quels référentiels je m'appuie, dans quel ordre je travaille, ce que je m'interdis, et à quel moment vous êtes prévenu. Rien de tout cela n'est négociable en cours de route.
L'outil pour couvrir, la main pour trouver.
Un test d'intrusion sérieux combine deux régimes de travail qu'on confond souvent. Le premier est mécanique : inventorier les points d'entrée, vérifier les versions, dérouler une liste de contrôles connus. Un outil le fait mieux et plus vite qu'un humain, et s'en priver n'aurait aucun sens.
Le second ne s'automatise pas. Il consiste à comprendre ce que votre application est censée faire, puis à chercher où cette intention n'a pas été traduite correctement dans le code. Aucun outil ne sait qu'un utilisateur ne devrait pas pouvoir valider sa propre demande de remboursement, parce que cette règle n'existe nulle part ailleurs que dans votre métier.
Toute ma méthode découle de ce partage. J'outille au maximum la première partie pour libérer du temps sur la seconde, qui est la seule à trouver les failles qui coûtent vraiment cher. Et aucun résultat d'outil n'entre dans un rapport sans avoir été rejoué à la main : sur un scan brut, la majorité des alertes remontées n'existent pas.
Sur quoi je m'appuie.
Les référentiels ne remplacent pas la recherche : ils garantissent qu'aucune famille de failles n'est passée sous silence pendant qu'on creuse ailleurs.
OWASP WSTG
Le guide de test des applications web. Il sert de liste de couverture : authentification, gestion de session, autorisation, validation des entrées, logique métier, configuration. Chaque catégorie est passée en revue et tracée.
OWASP API Security Top 10
Le classement propre aux API, qui ne recouvre pas celui du web. L'autorisation par objet et par fonction y occupe les premières places, et c'est effectivement là que se concentre l'essentiel de ce que je trouve.
Structure PTES
Pour la conduite de mission plutôt que pour le contenu technique : cadrage, collecte, modélisation des menaces, exploitation, post-exploitation, restitution. C'est la colonne vertébrale du déroulé.
Le déroulé d'une mission.
Cadrage et autorisation
Périmètre écrit, adresses concernées, fenêtre de test, contact joignable, comptes fournis. L'autorisation écrite est signée : sans elle, il n'y a pas de mission, quel que soit le prestataire. Le NDA précède tout échange technique.
Reconnaissance
Ce qui est réellement joignable à votre nom : sous-domaines, environnements annexes, technologies en place, points d'entrée oubliés. Cette phase est la seule où un périmètre plus large que prévu peut apparaître, et c'est le moment de le dire.
Cartographie fonctionnelle
Je parcours l'application comme un utilisateur légitime, avec chaque rôle, et je note ce que chacun peut faire. Cette carte est ce qui permettra ensuite de distinguer une requête normale d'un franchissement de frontière.
Recherche et exploitation
Le cœur de la mission. Chaque hypothèse est vérifiée sur l'application réelle, pas déduite d'une version affichée. Une faille n'entre dans le rapport que si je l'ai exploitée et que j'en ai la preuve reproductible.
Post-exploitation contrôlée
Une fois une brèche ouverte, je mesure jusqu'où elle mène : quelles données deviennent accessibles, quelles autres fonctions s'ouvrent, quel enchaînement devient possible. Je m'arrête à la démonstration, sans jamais extraire ni altérer de données réelles.
Rapport, restitution, retest
Rédaction, remise, puis une heure d'échange avec ceux qui vont corriger. Après déploiement des correctifs, je rejoue les tests concernés et je confirme par écrit ce qui est fermé.
Ce que je m'interdis.
Ces règles sont écrites dans chaque autorisation de test. Elles existent pour que la mission ne devienne jamais elle-même l'incident.
- Aucun déni de service, aucun test de charge, aucune tentative de saturation, sauf demande écrite et explicite de votre part.
- Aucune action destructrice sur des données réelles : pas de suppression, pas de modification de contenu appartenant à vos utilisateurs.
- Aucune extraction de données personnelles au-delà de la preuve minimale nécessaire pour démontrer la faille.
- Aucun test en dehors du périmètre écrit, même si une porte voisine paraît ouverte. Elle est signalée, elle n'est pas franchie.
- Aucune ingénierie sociale visant vos collaborateurs, sauf mission spécifique convenue à l'avance.
- Toute vulnérabilité critique est signalée le jour même, sans attendre la remise du rapport.
- Journal horodaté des tests conservé, pour que vous puissiez distinguer mon activité d'une attaque réelle dans vos propres traces.
- Destruction des données de mission et des preuves après la période de conservation convenue.
Boîte noire, grise ou blanche.
Le niveau d'information que vous me donnez change ce que la mission peut atteindre. Dans la pratique, une seule option est presque toujours la bonne.
Boîte grise, le choix par défaut
Vous fournissez des comptes, pas le code. Je pars du même point qu'un attaquant qui a réussi à s'inscrire, ce qui est le scénario réel dans l'immense majorité des cas. Meilleure couverture pour un budget donné.
Boîte noire
Aucune information, aucun compte. Réaliste pour évaluer l'exposition d'une surface publique, mais coûteuse : une partie des jours part en reconnaissance plutôt qu'en recherche, et tout ce qui est derrière l'authentification reste hors de portée.
Boîte blanche
Accès au code source en lecture. Pertinent sur un composant sensible et spécifique : moteur de droits, calcul financier, cryptographie maison. Peu rentable sur une application complète.
Ce qui ne change jamais
Quelle que soit l'approche, les règles d'engagement, l'alerte immédiate sur critique et le retest inclus restent identiques.
Questions fréquentes.
Suivez-vous une norme reconnue ?
Je m'appuie sur l'OWASP Web Security Testing Guide et sur l'OWASP API Security Top 10, complétés par la structure du PTES pour la conduite de mission. Ce sont des référentiels de couverture : ils garantissent qu'aucune famille de failles n'est oubliée. Ils ne remplacent pas la recherche propre à votre application, qui est l'essentiel du travail.
Boîte noire, grise ou blanche : laquelle choisir ?
La boîte grise dans la quasi-totalité des cas : vous fournissez des comptes, pas le code. C'est le meilleur rapport entre le réalisme et la couverture. La boîte noire complète fait perdre des jours en reconnaissance pour un gain de réalisme faible, et la boîte blanche n'a d'intérêt que sur du code sensible et spécifique.
Testez-vous en production ?
Oui, c'est même le cas le plus fréquent, et c'est sans danger dès lors que les règles sont posées : pas de déni de service, pas d'action destructrice, données de test créées pour l'occasion, requêtes espacées. Un environnement de recette fidèle reste préférable quand il existe, parce qu'il autorise des manipulations qu'on s'interdit ailleurs.
Que se passe-t-il si vous trouvez quelque chose de critique ?
Je vous préviens le jour même, sans attendre le rapport, avec de quoi comprendre et contenir immédiatement. C'est une règle fixée avant la mission, et c'est la raison pour laquelle je demande toujours un contact joignable pendant la fenêtre de test.
Utilisez-vous des outils automatiques ?
Oui, pour ce qu'ils font bien : inventorier, répéter, mesurer, ne rien oublier de mécanique. Aucun résultat d'outil n'entre dans le rapport sans avoir été rejoué et confirmé à la main. L'outillage couvre ce qui est déjà catalogué, ce qui libère du temps pour ce qui vous est propre.
Pour aller plus loin.
Combien coûte un pentest
Cette méthode se traduit en jours de recherche. Les six variables qui déterminent le montant, et ce qui est compris dans chaque mission.
DécouvrirPentest ou scan de vulnérabilités
Où s'arrête l'outil, où commence la recherche manuelle, et pourquoi les deux ne répondent pas à la même question.
DécouvrirParlons de votre périmètre.
Décrivez ce que vous voulez faire tester et je vous propose un cadrage : approche, phases, durée et règles d'engagement, avant tout engagement de votre part. Premier échange sans engagement, confidentialité totale.