Exemple de mission

Pentest Web : Plateforme e-commerce

PME e-commerce

3 jours

Application PHP

Pentest Web

Contexte et résultats adaptés à des fins d’illustration et de confidentialité.

Contexte de la mission

Le défi

Contexte

Une PME e-commerce souhaitait faire tester la sécurité de sa plateforme de vente en ligne, qui traitait des paiements bancaires et gérait un espace client avec plusieurs niveaux d'accès.

Aucun test de sécurité n'avait été réalisé depuis la mise en ligne de la plateforme.

Objectifs

Identifier les failles permettant l'accès aux données sensibles (clients, paiements)
Vérifier la sécurité des mécanismes de connexion et de création de compte
Évaluer la sécurité de l'interface d'administration
Fournir un plan de correction priorisé

Déroulement

Découvertes clés

Périmètre testé

Parcours client complet (inscription, commande, paiement, espace personnel)
Interfaces de l'application (API)
Mécanismes de connexion et gestion de session
Interface d'administration

Méthodologie

Test d’intrusion avec des comptes de test fournis, selon une approche dite en boîte grise. Les vérifications s’appuient sur le guide OWASP de test des applications web et une analyse ciblée du code des fonctions sensibles.

Critique

Un utilisateur pouvait s'attribuer le rôle administrateur en modifiant sa requête d'inscription

Critique

Les clés de paiement étaient accessibles depuis l'interface d'administration

Élevé

Aucune journalisation des actions sensibles (connexions, modifications de rôles)

Moyen

Absence d'authentification multifacteur sur les comptes administrateurs

Résultats

Bilan et recommandations

Bilan

15 vulnérabilités : 2 critiques, 3 élevées, 5 moyennes, 5 faibles

Dès le premier jour, un utilisateur a pu s’attribuer le rôle administrateur à l’inscription en modifiant un champ de la requête puis accéder aux clés de paiement présentes dans l’interface d’administration.

Le test a identifié 15 vulnérabilités dont 2 critiques. Les journaux disponibles ne permettaient pas de retracer les changements de rôle ni d’établir si ce chemin avait déjà été utilisé.

L’équipe a corrigé l’attribution des rôles côté serveur et remplacé les secrets exposés. Un test de suivi a confirmé qu’un compte client ne pouvait plus obtenir les mêmes accès.

Recommandations

Valider le rôle utilisateur côté serveur
Activer l'authentification multifacteur sur les comptes administrateurs
Mettre en place une journalisation des actions sensibles
Ne pas exposer les clés de paiement dans l'interface d'administration
Réaliser un test d'intrusion avant chaque mise en production majeure

Enseignements

Leçons apprises

Le rôle envoyé par le navigateur était accepté sans contrôle suffisant, si bien que la modification d’un seul champ a donné accès à l’administration.
La première faille a exposé les clés de paiement disponibles dans l’interface, ce qui a nécessité leur remplacement après la correction du contrôle des rôles.
L’absence de traces sur les changements de rôle limitait l’analyse des actions antérieures, ce qui a conduit à ajouter cette journalisation au plan de correction.

Continuité

Prochaines étapes

Ajouter des tests de non-régression sur l’attribution des rôles et les accès à l’administration
Prévoir un nouveau pentest avant la prochaine mise en production majeure
Mise en place d’une journalisation centralisée