Notre méthodologie de test d’intrusion des applications web

La meilleure vulnérabilité que j’ai trouvée le trimestre dernier ne figurait pas dans le rapport du scanner. Elle est apparue pendant l’heure creuse qui suit la fin d’un scan, au quatrième passage sur un tunnel de commande, quand j’ai remarqué que l’order_id d’une requête de confirmation n’était qu’un simple entier incrémenté. On retire un. On renvoie la requête. L’adresse de livraison de quelqu’un d’autre revient. Cet écart – entre ce qu’un outil signale et ce qu’un attaquant en fait réellement – est précisément la raison pour laquelle notre méthodologie de test d’intrusion d’applications web est construite ainsi.

Ce qui suit est le processus que nous suivons sur de vraies missions, pas une diapositive tirée d’un argumentaire commercial. L’ordre s’adapte selon l’application. La structure, elle, reste la même. Chaque étape alimente la suivante.

Points clés à retenir

• Une vraie méthodologie de test d’intrusion d’applications web repose avant tout sur le travail manuel. Les scanners gèrent la couverture et le bruit ; ce sont les humains qui débusquent les failles de contrôle d’accès et de logique métier que les outils sont structurellement incapables de voir.
• Nous travaillons par étapes : cadrage et reconnaissance, cartographie, authentification et gestion de session, contrôle d’accès, injection, logique métier, puis rédaction du rapport et contre-test pour confirmer que les correctifs ont bien été appliqués.
• Les découvertes à plus fort impact sont généralement les failles de contrôle d’accès (IDOR) et les abus de logique métier, pas des corruptions mémoire exotiques. Elles correspondent à la catégorie OWASP Top 10 A01 et restent les vulnérabilités critiques les plus fréquentes que nous documentons.
• Une découverte sans preuve de concept reproductible ni correctif précis n’est qu’une demi-découverte. Le rapport, c’est le produit.
• Le contre-test compte autant que le test lui-même. Un ticket marqué “corrigé” que personne n’a revérifié est une façon courante de voir une vulnérabilité bien vivante partir en production.

Ce qu’est réellement un test d’intrusion d’applications web

Un test d’intrusion d’applications web est une simulation d’attaque autorisée, orientée objectif, menée contre une application précise par un humain qui emploie les mêmes outils et le même état d’esprit qu’un véritable attaquant. Le but n’est pas de dresser une liste de faiblesses théoriques. Le but est de prouver lesquelles sont exploitables, jusqu’où elles mènent, et ce à quoi un intrus déterminé ou un utilisateur connecté malveillant pourrait réellement accéder.

Cette distinction commande tout le reste. Un scan pose la question : ce motif existe-t-il ? Un pentest pose la question : puis-je transformer cela en accès à des données ou à de l’argent ? La seconde question est plus difficile. Elle s’automatise mal. Et c’est précisément là que réside la valeur.

Étape 1 : cadrage, règles d’engagement et reconnaissance

Avant qu’une seule requête ne parte, nous fixons le périmètre par écrit. Quels noms d’hôte et sous-domaines sont concernés. Quel environnement – nous insistons fermement pour un miroir de préproduction plutôt que des données clients réelles. Quels rôles nous obtenons, si nous testons en tant qu’intrus non authentifié, utilisateur à faibles privilèges, ou les deux, et quels endpoints sont hors limites. Les règles d’engagement ne sont pas de la paperasse. Obtenir des comptes de test à deux niveaux de privilège distincts est souvent le seul facteur qui détermine si nous pourrons prouver une faille de contrôle d’accès.

La reconnaissance cartographie ensuite la surface d’attaque. Nous énumérons les sous-domaines, récupérons les bundles JavaScript et les analysons pour y trouver des routes d’API cachées et des clés en dur, lisons toute définition Swagger ou OpenAPI, et identifions la stack technique. Une SPA moderne divulguera volontiers l’intégralité de son contrat backend dans un fichier JS accompagné de sa source map. Lire ce fichier attentivement vaut toujours mieux que de tout deviner.

Étape 2 : cartographier l’application

Nous pilotons alors l’application à la main, avec Burp Suite en proxy sur tout le trafic. Chaque rôle, chaque parcours, chaque changement d’état. S’inscrire, se connecter, réinitialiser un mot de passe, téléverser un fichier, acheter quelque chose, inviter un collègue, modifier un rôle, supprimer un objet. L’historique du proxy issu d’un parcours minutieux devient la carte à partir de laquelle nous attaquons.

Pour les chemins vers lesquels l’interface ne pointe jamais, nous lançons ffuf et le crawler de Burp afin de découvrir contenus et paramètres. De vieux panneaux d’administration. Des routes de debug. Un /api/v1 oublié qui n’a jamais reçu les contrôles d’autorisation que quelqu’un a greffés sur v2. Ce dernier cas revient sans arrêt.

ffuf -w wordlist.txt -u https://app.example.com/api/FUZZ \
  -H "Authorization: Bearer <low-priv-token>" \
  -mc 200,201,401,403 -o results.json

Étape 3 : authentification et gestion de session

L’authentification a son propre chantier, parce qu’une erreur y est catastrophique et qu’une erreur subtile y est partout. Nous testons les flux de réinitialisation de mot de passe pour déceler la prédictibilité des jetons et l’empoisonnement de l’en-tête Host. Nous vérifions si les sessions meurent vraiment à la déconnexion et au changement de mot de passe, ou si elles font seulement semblant. Nous examinons de près la gestion des JWT : confusion d’algorithme, absence de vérification de signature, alg: none, jetons qui n’expirent jamais. Et nous sondons les flux multifacteurs pour y trouver la faille classique où le second facteur est imposé dans l’interface mais pas sur l’appel d’API sous-jacent.

Quelque chose que nous constatons sur un nombre déprimant d’applications : une limitation de débit sur le formulaire de connexion, aucune sur l’endpoint JSON qui se trouve derrière. Si le front-end freine et que l’API laisse passer, le credential stuffing entre comme dans un moulin.

Étape 4 : contrôle d’accès – là où vivent les vulnérabilités critiques

Les failles de contrôle d’accès correspondent à OWASP Top 10 A01, et c’est la catégorie qui produit la plupart de nos découvertes critiques. Le cas classique est l’IDOR (insecure direct object reference, CWE-639) : un identifiant d’objet, présent dans une requête, auquel le serveur fait confiance sans jamais vérifier si l’utilisateur courant est bien le propriétaire de cet objet.

Voilà pourquoi deux comptes de test comptent. Nous capturons une requête en tant qu’utilisateur A, la rejouons en tant qu’utilisateur B en n’échangeant que l’identifiant d’objet ou le jeton de session, et observons si l’utilisateur B repart avec les données de l’utilisateur A.

GET /api/v2/invoices/48213 HTTP/1.1
Host: app.example.com
Authorization: Bearer <user-B-token>

# Invoice 48213 belongs to user A.
# A 200 with A's data means IDOR.

Nous testons aussi l’élévation verticale (un utilisateur standard peut-il atteindre une fonction réservée aux administrateurs en appelant directement l’endpoint ?), le mass assignment (ajouter "role":"admin" au corps d’une requête de mise à jour de profil est-il réellement pris en compte ?), et le forçage d’accès à des fonctions que le menu cache mais que le serveur continue de servir. Les scanners passent à côté de la quasi-totalité de tout cela. Ils n’ont aucune notion de qui est censé posséder quoi. Ce contexte vit dans la tête du testeur.

Étape 5 : injection et failles côté serveur

L’injection est bien comprise, et elle n’a pas disparu. Elle s’est déplacée. Nous cherchons toujours la SQL injection avec des payloads manuels et automatisés, mais les heures passent désormais dans les variantes que les frameworks n’ont pas résolues à votre place : injection de template côté serveur, SSRF où un paramètre d’URL amène le serveur à récupérer des ressources internes (une ligne droite vers les endpoints de métadonnées cloud), traitement d’entités externes XML sur tout ce qui ingère encore du XML, et injection de commandes dissimulée dans le traitement de fichiers ou les fonctions d’export.

Le cross-site scripting est toujours partout, en particulier le XSS basé sur le DOM dans les SPA, où une valeur circule depuis l’URL jusque dans innerHTML ou un puits (sink) de framework sans la moindre neutralisation. Nous confirmons chaque candidat à la main. Une valeur réfléchie dans une réponse ne prouve rien. L’exécution dans un navigateur, elle, le prouve.

Étape 6 : logique métier – la partie que les outils ne savent pas faire

C’est dans les tests de logique métier que l’expérience distingue une vraie évaluation d’un PDF issu d’un simple scan-and-dump. Il n’existe aucune signature pour “le coupon s’applique deux fois”, ou “on peut sauter l’étape de paiement et atterrir quand même sur l’offre payante”, ou “le champ quantité accepte un nombre négatif et crédite votre compte”. Ces cas ne deviennent des découvertes que lorsqu’un humain comprend ce que l’application est censée faire, puis casse délibérément l’hypothèse qui la sous-tend.

Sur nos missions, nous trouvons régulièrement des race conditions dans les flux d’utilisation de crédits et de retrait – on envoie la même requête vingt fois en parallèle et on regarde si une action à usage unique se déclenche deux fois. Des étapes de parcours que l’on peut réordonner ou sauter. Des limites imposées uniquement côté client. Cette catégorie apparaît rarement dans les sorties automatisées, et c’est souvent là que se logent les dégâts les plus lourds dans le monde réel.

Étape 7 : rédaction du rapport et contre-test

Le rapport est le livrable, alors nous le rédigeons pour deux lecteurs à la fois. Les dirigeants reçoivent une synthèse classée par niveau de risque, exprimée en termes métier. Les développeurs reçoivent une fiche par découverte : la sévérité (nous la notons avec le CVSS, mais nous la tempérons toujours au regard de l’exploitabilité réelle dans votre contexte), la reproduction pas à pas, la requête ou le payload exact, et un correctif concret. Pas “assainissez les entrées”. Quel contrôle ajouter, et où.

Ensuite, nous effectuons le contre-test. Une fois que votre équipe a livré les correctifs, nous rejouons exactement les attaques qui fonctionnaient pour confirmer qu’elles sont mortes, et nous vérifions que nous n’avons pas ouvert une brèche juste à côté. On ne se sort pas d’une découverte avec des mots ; le payload se déclenche ou ne se déclenche pas. Une remédiation que personne n’a vérifiée, voilà comment une vulnérabilité “fermée” atteint discrètement la production.

Comment CyberXplore vous aide

Cette méthodologie est exactement celle que nous appliquons dans le cadre de notre service de test d’intrusion d’applications web : des testeurs seniors, un travail avant tout manuel, un rapport sur lequel vos développeurs peuvent agir, et un contre-test inclus, pour que vous payiez des correctifs qui tiennent, pas un PDF qui prend la poussière. Besoin d’aide pour le cadrage ou d’une réponse franche sur la charge et le calendrier pour votre application ? Demander un devis et nous parcourrons votre surface avec vous avant que vous ne vous engagiez à quoi que ce soit.

FAQ

Combien de temps dure un test d’intrusion d’applications web ?

Pour une application de taille moyenne classique, comptez environ une à deux semaines de tests actifs, plus quelques jours pour la rédaction du rapport. La durée évolue avec le nombre de rôles, d’endpoints et de parcours dans le périmètre. Les applications à forte logique métier ou à multiples niveaux de privilège prennent plus de temps, parce que ce sont justement les parties que l’on ne peut pas bâcler. C’est le cadrage en amont qui garde l’estimation honnête.

Quelle est la différence entre un scan et un test d’intrusion ?

Un scan de vulnérabilités est une reconnaissance de motifs automatisée qui remonte des signatures connues et génère quantité de faux positifs. Un test d’intrusion, c’est un humain qui attaque l’application pour prouver un impact réel et exploitable, y compris les failles de contrôle d’accès et de logique métier que les scanners ne savent pas détecter. Nous utilisons des scanners au sein d’un pentest pour la couverture. Ils sont le début du travail, pas sa totalité.

Avez-vous besoin d’un accès à la production ou d’un environnement de préproduction ?

Nous préférons un environnement de préproduction ou de staging qui reproduit le comportement de la production, idéalement peuplé de données de test plutôt que de vrais enregistrements clients. Cela nous permet de tester de façon agressive sans mettre en danger les données réelles ni la disponibilité. Si seule la production est disponible, nous adaptons les règles d’engagement pour tester en toute sécurité et éviter les actions destructrices.

Pourquoi demandez-vous plusieurs comptes utilisateurs et rôles ?

Parce que la plupart des découvertes critiques sont des défaillances de contrôle d’accès, et qu’on ne peut en prouver une sans deux perspectives. Tester en tant qu’utilisateur A puis utilisateur B confirme si le serveur vérifie réellement la propriété. Tester un compte à faibles privilèges contre des fonctions d’administration révèle l’élévation verticale. Sans ces comptes, nous pouvons soupçonner ces vulnérabilités mais pas les démontrer.

Le contre-test est-il inclus ?

Oui. Une fois que votre équipe a remédié, nous rejouons les attaques qui avaient réussi, confirmons que les correctifs tiennent, et mettons à jour le statut dans le rapport. Une découverte n’est pas vraiment close tant que personne n’a vérifié que le correctif fonctionne, et cette vérification fait partie de la mission plutôt que d’être une option en supplément.

Cette méthodologie couvre-t-elle les API et les SPA ?

Oui. Une application web moderne est généralement une SPA qui dialogue avec une API JSON ou GraphQL, si bien que l’API concentre une grande partie de notre temps. Nous analysons les bundles front-end pour cartographier le contrat backend, puis testons directement les endpoints de l’API à la recherche de failles d’autorisation, d’injection et de logique, au lieu de faire confiance à ce que l’interface expose.