Le Web Application Penetration Testing (WAPT) est une simulation contrôlée d’une attaque réelle sur une application web. L’objectif est d’identifier les vulnérabilités — qu’elles soient évidentes ou cachées — avant qu’elles ne puissent être exploitées par un attaquant. Ce guide décrit les phases opérationnelles d’un WAPT, les outils les plus utilisés et les erreurs à éviter, avec une approche pratique destinée aux professionnels de l’informatique et aux responsables de la sécurité.

1. Configuration de l’environnement de test

Avant de lancer toute activité, il est nécessaire de préparer un environnement isolé et contrôlé. Les composants fondamentaux sont :

• Kali Linux : distribution de référence pour les tests de pénétration, avec une vaste gamme d’outils préinstallés, notamment des scanners de vulnérabilités, des analyseurs de trafic et des frameworks d’exploitation.
• Machine virtuelle : isole l’environnement de test du système d’exploitation hôte, contenant les éventuels effets secondaires des activités menées.
• Burp Suite : outil essentiel pour intercepter et manipuler les requêtes HTTP. Configuré comme proxy, il permet d’analyser le trafic entre le navigateur et l’application web et de détecter des vulnérabilités dans le flux des communications.

2. Collecte d’informations

Une collecte précise des informations est la base de tout test efficace. Elle s’articule autour de deux activités principales :

• Footprinting : collecte d’informations publiquement disponibles sur la cible, y compris les éventuelles fuites de données indexées par les moteurs de recherche et la cartographie des points d’entrée de l’application.
• Énumération : identification des applications présentes sur le serveur, fingerprinting du framework utilisé et reconstruction de l’architecture pour identifier les vulnérabilités connues associées aux technologies détectées.

3. Évaluation des vulnérabilités

Dans cette phase, on combine des outils automatiques et une analyse manuelle pour obtenir une cartographie complète des vulnérabilités présentes :

• Nmap : scan des ports et identification des services actifs sur la cible, utile pour détecter des surfaces d’attaque non surveillées.
• OWASP ZAP : scanner automatique pour les vulnérabilités courantes dans les applications web, telles que les injections SQL et le cross-site scripting (XSS).
• Nikto : scanner spécifique pour les serveurs web, orienté vers l’identification de configurations erronées et de vulnérabilités connues au niveau de l’infrastructure.

4. Exploitation

La phase d’exploitation vérifie si les vulnérabilités identifiées sont réellement exploitables. Les types les plus fréquents dans les applications web sont :

• Injection SQL : permet l’exécution de commandes SQL non autorisées. SQLmap automatise la détection et l’exploitation de ces vulnérabilités, y compris l’injection SQL aveugle (blind SQL injection).
• Injection de commandes : permet l’exécution de commandes arbitraires sur le serveur. L’identification nécessite des techniques de test manuel ciblées.
• Cross-Site Scripting (XSS) : permet l’injection de scripts malveillants dans les pages web. Burp Suite prend en charge l’identification des variantes réfléchies et stockées.
• Directory Traversal : permet l’accès non autorisé à des fichiers sur le serveur. Des outils comme DotDotPwn automatisent ce type d’attaque.
• Insecure Direct Object References (IDOR) : vulnérabilités qui permettent d’accéder à des ressources non autorisées en manipulant les paramètres des requêtes.

---

Exemple pratique sur une application de démonstration

Des applications vulnérables comme OWASP WebGoat ou Damn Vulnerable Web App (DVWA) offrent un environnement sûr pour s’exercer. Un exemple typique est l’exploitation d’une vulnérabilité d’injection SQL via SQLmap : l’outil identifie le paramètre vulnérable, extrait la structure de la base de données et récupère les données, démontrant concrètement l’impact de la vulnérabilité.

---

5. Analyse de la logique métier

Les vulnérabilités dans la logique métier sont parmi les plus difficiles à détecter avec des outils automatiques. Elles concernent des défauts dans le flux applicatif prévu : par exemple, la possibilité de sauter des étapes obligatoires dans un processus d’achat, de modifier les prix côté client ou d’accéder à des fonctionnalités réservées sans les autorisations nécessaires. Cette phase nécessite une compréhension du contexte applicatif et ne peut être déléguée entièrement aux scanners.

6. Post-exploitation

Une fois qu’une vulnérabilité a été exploitée, la phase de post-exploitation évalue l’impact réel pour l’organisation :

• Escalade de privilèges : vérifie s’il est possible d’obtenir un accès administratif au système à partir d’un accès initial limité.
• Exfiltration de données : identifie quelles données sensibles seraient accessibles et par quels chemins, y compris les méthodes éventuelles pour contourner les contrôles de sécurité existants.

Erreurs courantes à éviter

• Sauter la collecte d’informations : une analyse préliminaire insuffisante réduit considérablement la qualité du test.
• Se fier uniquement aux scanners automatiques : les outils automatiques ne détectent pas les vulnérabilités logiques ou contextuelles ; le test manuel est indispensable.
• Négliger la logique métier : certaines des vulnérabilités les plus critiques ne ressortent pas des scans techniques.
• Effectuer des tests en production : les tests sur des environnements de production peuvent causer des interruptions de service et avoir un impact sur les données réelles.
• Ne pas documenter les résultats : sans un rapport structuré, les vulnérabilités identifiées risquent de ne pas être résolues de manière systématique.

Questions fréquentes

• Quelle est la différence entre un Vulnerability Assessment et un Web Application Penetration Test ?
• Le Vulnerability Assessment identifie et catalogue les vulnérabilités présentes, sans en vérifier l’exploitation effective. Le WAPT va plus loin : il simule une attaque réelle pour vérifier si les vulnérabilités sont concrètement exploitables et quel impact elles auraient sur l’application et les données.
• À quelle fréquence est-il conseillé d’effectuer un WAPT ?
• En général, au moins une fois par an et chaque fois que des modifications significatives sont apportées à l’application. Pour les applications critiques ou traitant des données sensibles, une fréquence plus élevée est recommandée.
• Le WAPT nécessite-t-il l’accès au code source ?
• Pas nécessairement. Un test “black-box” est mené sans accès au code, simulant un attaquant externe. Un test “white-box” inclut l’analyse du code source et produit des résultats plus approfondis. Le choix dépend des objectifs et du contexte du test.
• Quelles réglementations exigent ou recommandent le test de pénétration sur les applications web ?
• PCI DSS exige explicitement des tests de pénétration périodiques pour les systèmes traitant des données de paiement. NIS2 et ISO/IEC 27001 recommandent des activités de vérification de la sécurité, y compris les tests de pénétration, dans le cadre d’un programme structuré de gestion des risques.
• Que doit contenir le rapport final d’un WAPT ?
• Un rapport efficace inclut un résumé exécutif pour la direction, la description technique de chaque vulnérabilité avec sa classification de gravité (ex. CVSS), la preuve d’exploitation et les recommandations de remédiation priorisées.

Approfondissements utiles

Si vous évaluez comment structurer la sécurité de vos applications ou de l’ensemble de votre infrastructure, ces services peuvent vous aider à définir le parcours le plus adapté :

• Web Application Penetration Testing — le service WAPT d’ISGroup : simulation manuelle d’attaque sur des applications web avec les méthodologies OSSTMM et OWASP.
• Préparation et planification d’un WAPT — comment définir le périmètre, les autorisations, l’environnement de test et la remédiation avant l’exécution.
• OWASP Top Ten en action — exemples de vulnérabilités applicatives à vérifier lors d’un test de pénétration web.
• Vulnerability Assessment — activités non invasives pour identifier les vulnérabilités connues sur les infrastructures et les applications, utile comme point de départ ou comme activité récurrente.
• Code Review — analyse “white-box” du code source pour identifier les vulnérabilités qui n’apparaissent pas lors des tests dynamiques.
• Vulnerability Management Service — gestion continue des vulnérabilités avec des scans périodiques, des rapports et un support opérationnel à la remédiation.