Les applications web sont de plus en plus critiques pour les activités des entreprises et, parallèlement, de plus en plus exposées aux attaques. De nombreuses vulnérabilités naissent d’une gestion inappropriée des entrées (input) et de contrôles insuffisants lors du développement.

Le test d’intrusion (penetration testing) sur les applications web simule une attaque réelle : il vérifie l’infrastructure sous-jacente, analyse les points d’entrée et tente d’obtenir le compromis le plus profond possible. Cet article illustre des cas représentatifs où des vulnérabilités de l’OWASP Top Ten ont été identifiées et résolues grâce à des activités de test d’intrusion.

1. Injection SQL dans une application e-commerce

Failles d’injection (OWASP A03)

Les vulnérabilités d’injection se produisent lorsque des données non validées sont envoyées à un interpréteur dans le cadre d’une commande ou d’une requête. Dans le cas de l’injection SQL, un attaquant peut exécuter des commandes non autorisées sur la base de données ou accéder à des données confidentielles.

Découverte via un test d’intrusion

Lors d’un test d’intrusion sur une application e-commerce, les champs de saisie — barre de recherche et formulaire de connexion — se sont révélés vulnérables à l’injection SQL. En injectant du code SQL malveillant, le testeur a pu contourner l’authentification, récupérer des données sensibles des clients et modifier les prix des produits.

Exemple d’exploit

Dans le champ nom d’utilisateur d’un formulaire de connexion, l’insertion de ' OR '1'='1 exploite la logique de la requête SQL pour contourner le contrôle des identifiants.

Solutions adoptées

• Validation des entrées : n’autoriser que les caractères et formats attendus, en rejetant tout le reste.
• Requêtes paramétrées (prepared statements) : l’entrée de l’utilisateur est traitée comme une donnée, et non comme du code exécutable.
• Principe du moindre privilège : limiter les permissions des utilisateurs de la base de données au strict nécessaire pour le fonctionnement de l’application.

L’application a ainsi prévenu des violations potentielles de données et protégé les informations des clients.

2. Cross-Site Scripting dans une application bancaire

XSS (OWASP A07)

Les vulnérabilités XSS se produisent lorsqu’une application web inclut des données non validées dans une réponse envoyée au navigateur. Un attaquant peut exécuter des scripts malveillants dans le contexte du navigateur de la victime, voler des sessions, effectuer des défigurations (defacement) ou rediriger les utilisateurs vers des sites malveillants.

Découverte via un test d’intrusion

Le tableau d’affichage des messages de l’application ne nettoyait pas correctement les entrées des utilisateurs. Un attaquant pouvait injecter du code JavaScript malveillant dans un message, qui était ensuite exécuté dans le navigateur de quiconque visualisait cette section.

Exemple d’exploit

1. L’attaquant publie un message contenant du code JavaScript conçu pour voler les cookies de session ou rediriger l’utilisateur vers un site de phishing.
2. Lorsqu’un autre utilisateur consulte le message, le code est exécuté dans son navigateur.

Solutions adoptées

• Encodage de sortie (Output encoding) : encoder toutes les sorties fournies par l’utilisateur avant de les afficher dans le navigateur.
• Échappement contextuel : appliquer des techniques d’échappement en fonction du contexte d’affichage (HTML, JavaScript, URL).
• Content Security Policy (CSP) : mettre en œuvre une politique rigoureuse pour contrôler les ressources que le navigateur est autorisé à charger.

L’application bancaire a ainsi protégé les sessions des utilisateurs et prévenu les accès non autorisés.

Autres vulnérabilités OWASP Top Ten à considérer

L’injection SQL et le XSS sont parmi les plus répandus, mais l’OWASP Top Ten couvre un ensemble plus large de risques que tout programme de test d’intrusion devrait aborder :

• Authentification compromise : mettre en œuvre une authentification multifacteur, des politiques de mots de passe robustes et une gestion correcte des sessions.
• Configuration non sécurisée : configurer correctement les applications, frameworks, serveurs et bases de données, en maintenant toutes les mises à jour de sécurité.
• Références directes à des objets non sécurisées (IDOR) : mettre en œuvre des contrôles d’accès pour empêcher l’accès direct aux ressources basé sur les entrées de l’utilisateur.
• Contrôle d’accès défaillant au niveau des fonctions : vérifier côté serveur l’autorisation des utilisateurs pour chaque fonctionnalité exposée.
• Cross-Site Request Forgery (CSRF) : utiliser des jetons anti-CSRF pour empêcher des actions indésirables effectuées au nom de l’utilisateur authentifié.
• Composants avec des vulnérabilités connues : mettre à jour régulièrement les bibliothèques, frameworks et dépendances pour corriger les vulnérabilités publiquement connues.
• Redirections et transferts non validés : valider et nettoyer les entrées de l’utilisateur pour empêcher les redirections vers des sites malveillants.

Ce que ces cas nous enseignent

1. Sécurité proactive : le test d’intrusion régulier permet d’identifier les vulnérabilités avant qu’elles ne soient exploitées en production.
2. Défense en profondeur : aucun contrôle unique n’est suffisant ; la combinaison de plusieurs mesures réduit considérablement la surface d’attaque.
3. Surveillance continue : les applications web évoluent ; les contrôles de sécurité doivent évoluer avec elles.
4. Formation des développeurs : la sensibilisation aux vulnérabilités courantes réduit le nombre de défauts introduits lors du développement.
5. Conformité réglementaire : le test d’intrusion est souvent exigé par des normes telles que PCI DSS, ISO/IEC 27001 et la directive NIS2.

---

Questions fréquentes

• Qu’est-ce que l’OWASP Top Ten et pourquoi est-ce pertinent pour le test d’intrusion ?
• L’OWASP Top Ten est un document de référence qui liste les dix catégories de vulnérabilités les plus critiques pour les applications web, mis à jour périodiquement par la communauté OWASP. Il constitue la base méthodologique de nombreux programmes de test d’intrusion car il couvre les risques statistiquement les plus fréquents et à fort impact.
• À quelle fréquence un test d’intrusion devrait-il être effectué sur une application web ?
• La fréquence dépend du contexte : en général, un test annuel est recommandé, mais il doit également être effectué après chaque mise à jour significative, modification de l’infrastructure ou changement dans les exigences de conformité. Des normes comme PCI DSS imposent des fréquences spécifiques.
• Quelle est la différence entre l’évaluation des vulnérabilités (vulnerability assessment) et le test d’intrusion ?
• L’évaluation des vulnérabilités identifie et classe les vulnérabilités présentes dans un système, sans nécessairement les exploiter. Le test d’intrusion va plus loin : il tente activement d’exploiter les vulnérabilités pour évaluer l’impact réel et la profondeur du compromis accessible à un attaquant.
• Les vulnérabilités de l’OWASP Top Ten concernent-elles uniquement les applications web ?
• L’OWASP Top Ten a été créé pour les applications web, mais bon nombre de ses principes — tels que la validation des entrées, le contrôle des accès et la gestion sécurisée des sessions — s’appliquent également aux API, aux applications mobiles et aux microservices. L’OWASP publie également des listes dédiées à ces contextes.
• Que se passe-t-il après un test d’intrusion : comment gérer la remédiation ?
• À la fin du test, un rapport est produit, classant les vulnérabilités par gravité et incluant des recommandations opérationnelles. L’équipe de développement ou le fournisseur de l’application met en œuvre les corrections, après quoi il est recommandé d’effectuer un re-test pour vérifier que les vulnérabilités ont été effectivement résolues.

---

Approfondissements utiles

• Test d’intrusion d’applications web — comment ISGroup vérifie la sécurité des applications web en simulant un attaquant réel.
• Guide du test d’intrusion pour les applications web — comment transformer les risques OWASP en activités de test opérationnelles.
• Le rôle du partenaire spécialisé en WAPT — critères pour choisir qui doit effectuer les tests, les rapports et la remédiation.
• Test d’intrusion réseau — vérification manuelle de l’infrastructure IT pour identifier des points critiques que les scanners automatiques ne détectent pas.
• Évaluation des vulnérabilités — activités non invasives pour identifier les vulnérabilités connues et maintenir un niveau de sécurité élevé.
• Revue de code — analyse du code source pour détecter des vulnérabilités non apparues lors des tests dynamiques.
• Ethical Hacking — simulation d’attaques complexes impliquant l’infrastructure, les personnes et la sécurité physique.
• Formation — parcours pratiques pour les développeurs et les équipes de sécurité sur le codage sécurisé et les meilleures pratiques OWASP.