Pentest web
Nous reproduisons le travail d'un attaquant sur votre site, votre espace client ou votre application métier : obtenir un accès, lire des données qui ne nous appartiennent pas, passer d'un compte à un autre.
C'est le périmètre le plus exposé : votre site est accessible en permanence, depuis n'importe où, par n'importe qui. C'est aussi celui où une faille se corrige souvent en quelques heures, une fois qu'on sait où regarder.
3 à 8 j
Durée typique selon le nombre de fonctionnalités
OWASP
Référentiel de base, complété par des tests de logique métier
Le jour même
Délai d'alerte si une faille critique est trouvée
Des tests manuels, en plus des outils automatiques
Les référentiels que nous suivons
Le test ne dépend pas de l'inspiration du jour : il suit des méthodes publiques et reconnues, que vos équipes et vos clients peuvent vérifier.
Les dix catégories de failles les plus répandues sur le web. C'est le socle attendu par la plupart des clients et des assureurs.
Le guide de test applicatif de l'OWASP : la liste des contrôles à mener, poste par poste, de l'authentification à la logique métier.
Le référentiel de vérification, utilisé pour situer votre application à un niveau d'exigence et dire ce qui manque pour l'atteindre.
La notation des failles trouvées, complétée par la criticité réelle dans votre contexte.
Une application se casse surtout par sa logique
Nous nous installons devant votre application comme le ferait quelqu'un qui veut en tirer quelque chose : de l'argent, des données, ou un accès au serveur.
Ce que nous faisons
Nous prenons l'application par ce que le périmètre nous donne. Quand des comptes existent, nous les utilisons normalement avant de sortir du cadre prévu : modifier un identifiant dans une URL, rejouer une requête avec un autre compte, changer un prix entre deux étapes de commande. Quand la mission s'arrête à ce qui est accessible sans compte, le même raisonnement s'applique aux fonctions publiques. Chaque anomalie est poussée jusqu'à son impact réel.
Ce que vous en retirez
Un rapport qui sert les deux publics : une vue d'ensemble du risque, lisible par la direction, pour arbitrer et décider ; et le détail technique de chaque faille, avec la requête exacte qui l'emprunte et la remédiation à appliquer. Vos développeurs rejouent le constat en deux minutes au lieu de chercher ce que nous avons voulu dire.
Pourquoi c'est important
Un site public est attaqué en continu par des robots, et ciblé à la main dès qu'il traite de l'argent ou des données personnelles. Une faille de contrôle d'accès ne déclenche aucune alerte : elle ressemble à un usage normal, et peut durer des mois.
Tester ce que les protections protègent
Un pare-feu applicatif (WAF), une protection anti-robots ou une limitation du nombre de requêtes peuvent arrêter nos tests avant qu'ils n'atteignent l'application. Ce n'est pas systématique : nous commençons dans les conditions réelles, et nous ne demandons à passer au travers que si la protection nous bloque pour de bon.
Ce que nous demandons, le cas échéant
Si nous sommes bloqués, et toujours avec votre accord : nos adresses IP autorisées sur le WAF et les limitations de débit, ou un accès direct au serveur d'origine. Dans bien des missions, cela ne s'avère pas nécessaire.
Pourquoi
Une protection se contourne, expire ou saute un jour, souvent pendant une mise en production. Ce qu'il y a derrière doit tenir seul : il reste donc important de tester le cœur de l'application, même quand une protection se trouve devant. Rester bloqué au pare-feu ne dirait rien de votre application.
La protection est testée aussi
Avant de passer au travers, nous vérifions ce que le WAF bloque réellement. Le rapport indique, pour chaque faille, si la protection en place réduit le risque ou si elle le masque seulement. Lorsque nous avons été bloqués, il précise aussi ce que ce blocage nous a empêché de tester.
Boîte noire, boîte grise ou boîte blanche
Ces trois mots décrivent ce que vous nous donnez avant de commencer. Le choix change ce que le test couvre, et le temps qu'il demande.
Boîte noire
Nous démarrons sans rien : ni compte, ni documentation, ni schéma. C'est la position exacte d'un attaquant extérieur, donc le scénario le plus réaliste. En contrepartie, une partie du temps passe à chercher ce que vous auriez pu nous dire en deux minutes, et certaines zones ne sont jamais atteintes.
Boîte grise
Nous démarrons comme en boîte noire, avec quelques informations en réserve : un compte de test, la liste des domaines, un schéma réseau. Elles ne sortent que si nous bloquons ou si une piste mérite d'être creusée plus vite.
Boîte blanche
Vous donnez tout : un compte pour chaque rôle, la documentation, parfois le code source. La couverture est maximale et aucune fonction n'est oubliée, mais le test s'éloigne des conditions réelles d'une attaque.
Nous recommandons la boîte grise. On commence à l'aveugle, et l'information ne sort qu'au moment où elle évite de perdre une journée. Chaque information reçue en cours de mission est notée dans le rapport, avec le moment où elle nous a été donnée : vous savez ainsi ce qui a été trouvé seul et ce qui l'a été avec un coup de pouce.
Quatre phases, de la signature au rapport
Cadrage
Périmètre, URLs concernées, comptes de test, fenêtre d'intervention et personne à joindre en cas de problème, le tout par écrit.
Reconnaissance
Cartographie des pages, des rôles et des technologies. On comprend l'application avant de l'attaquer.
Exploitation
Tests manuels guidés par la reconnaissance, exploitation des failles trouvées et mesure de leur impact réel sur vos données.
Rapport & restitution
Rédaction, relecture, puis réunion pour parcourir les constats ensemble et décider de l'ordre des corrections.
Questions sur cette prestation
+Faut-il un environnement de préproduction ?
C'est préférable, mais pas obligatoire. Si les tests ont lieu en production, les actions à risque sont validées avec vous au préalable et menées dans la fenêtre que vous choisissez.
+Quelle différence avec un scan de vulnérabilités ?
Un scan liste des signaux automatiques ; un test d'intrusion enchaîne les failles pour démontrer ce qu'un attaquant obtient réellement. Le scan est un bon point de départ, mais il ne suffit pas à conclure.
+Faut-il vraiment désactiver le WAF ?
Pas entièrement : il suffit d'autoriser nos adresses. Nous vérifions d'abord ce que le WAF bloque, puis nous testons ce qu'il y a derrière. Sans cela, le rapport dirait surtout que votre WAF fonctionne, ce que vous savez déjà.
Les durées, délais et repères indiqués sont des ordres de grandeur pour une TPE ou PME ; ils sont confirmés dans le devis.