Tests d'intrusion d'applications web

Gjethe teste les applications web comme les abordent les attaquants : connexions et sessions, accès entre utilisateurs et rôles, traitement des entrées, paiements et logique métier. Les tests suivent les recommandations de l'OWASP, chaque constat est accompagné de preuves et d'une correction, et un nouveau test confirme que les problèmes ont disparu.

Réserver une consultation gratuite Demander un devis

Première consultation gratuite
Devis écrit pour votre projet
Paiements échelonnés par étapes, avec souplesse

Standards: OWASP Top 10, OWASP ASVS, WSTG
Axe de travail: Contrôle d'accès, logique, exposition des données
Approche: En général en boîte grise avec des comptes de test
Livrable: Rapport, corrections et nouveau test

Definition

Qu'est-ce que les tests d'intrusion d'applications web?

Le test d'intrusion d'une application web est une évaluation de sécurité manuelle d'un site ou d'une application web qui tente de contourner ses contrôles, d'atteindre des données qu'elle ne devrait pas exposer et de détourner ses fonctionnalités, afin de trouver et de corriger les faiblesses exploitables.

La plupart des problèmes graves des applications web n'ont rien d'exotique. Un utilisateur qui peut voir la facture d'un autre client en changeant un numéro dans la barre d'adresse. Une action d'administration qui vérifie le menu mais pas la requête qui se cache derrière. Une réinitialisation de mot de passe réutilisable. Tout cela semble normal en surface ; l'application fait simplement confiance à la mauvaise chose. Les trouver demande un testeur qui comprend comment l'application est censée fonctionner et qui vérifie délibérément que les règles sont appliquées côté serveur, et pas seulement masquées dans l'interface.

À qui s'adresse-t-elle ?

Produits SaaS
Plusieurs clients partagent un même système, la séparation entre les comptes doit donc être étanche.
Boutiques en ligne et systèmes de réservation
Le paiement, les remises, les stocks et les règlements sont des cibles fréquentes d'abus.
Portails avec données personnelles
Les portails clients, patients ou membres doivent montrer à chaque personne uniquement ses propres informations.
Équipes avant une version majeure
Un test avant le lancement est le moment le moins coûteux pour trouver des problèmes structurels.

Ce qui est inclus, et ce que vous conservez

Ce qui est inclus

Cartographie des pages, des fonctions et des rôles utilisateurs
Tests de l'authentification et de la réinitialisation de mot de passe
Revue de la gestion des sessions et des jetons
Tests du contrôle d'accès entre utilisateurs et rôles
Tests du traitement des entrées et des injections
Contrôles de la sortie et du traitement côté client
Revue de la gestion des envois et téléchargements de fichiers
Tests de la logique métier et des détournements de workflow
Revue de l'exposition des données sensibles
Revue des en-têtes de sécurité, des cookies et de TLS
Revue des scripts tiers et des dépendances
Rapport avec preuves, corrections et nouveau test

Ce que vous recevez

Remis en fin de mission. À vous pour toujours.

Rapport de test d'application web
Constats associés aux catégories OWASP
Description claire de chaque problème confirmé
Plan de correction priorisé
Rapport de nouveau test

Ce que nous vérifions toujours dans une application web

Un utilisateur peut-il lire ou modifier les données d'un autre ?
Un utilisateur normal peut-il accéder directement aux fonctions d'administration ?
Les connexions peuvent-elles être contournées ou réutilisées ?
Les réinitialisations de mot de passe et les invitations expirent-elles correctement ?
Les saisies de l'utilisateur sont-elles parfois traitées comme du code ou des requêtes ?
Les fichiers envoyés peuvent-ils nuire au serveur ou à d'autres utilisateurs ?
Les prix, les quantités ou les étapes d'un workflow peuvent-ils être manipulés ?
Les réponses contiennent-elles des données que la page n'affiche jamais ?

Pourquoi les problèmes de contrôle d'accès sont le constat le plus fréquent

Le contrôle d'accès défaillant figure en tête de l'OWASP Top 10, et ce n'est pas un hasard. Les frameworks gèrent automatiquement de nombreuses tâches de sécurité, mais ils ne peuvent pas savoir quels enregistrements appartiennent à quel client, ni quels boutons un manager peut actionner. Ces règles vivent dans votre code, écrites fonctionnalité par fonctionnalité, et une seule vérification manquante suffit.

Nous testons cela de façon systématique : les requêtes importantes sont rejouées sous d'autres utilisateurs et d'autres rôles, avec des identifiants modifiés, pour voir si le serveur applique la règle ou si seule l'interface masque l'option. C'est un travail minutieux et répétitif, et c'est de là que viennent de nombreux constats graves dans les applications modernes.

Domaines de l'OWASP Top 10 que nous couvrons

Domaine	Exemple de ce que nous vérifions
Contrôle d'accès défaillant	Consulter ou modifier les enregistrements d'autres utilisateurs
Défaillances cryptographiques	Données sensibles transmises ou stockées sans protection adéquate
Injection	Requêtes ou commandes construites à partir de saisies utilisateur
Conception non sécurisée	Workflows qui peuvent être détournés par conception
Mauvaise configuration de sécurité	Pages de débogage, paramètres par défaut, erreurs trop détaillées
Composants vulnérables	Bibliothèques obsolètes présentant des faiblesses connues
Défaillances d'authentification	Gestion faible des connexions, des sessions ou des réinitialisations
Intégrité des logiciels et des données	Mises à jour non sûres ou code tiers non fiable
Journalisation et supervision	Attaques qui passeraient inaperçues
Falsification de requêtes côté serveur	Le serveur qui récupère des adresses contrôlées par un attaquant

Tester les parties d'une application que les scanners ignorent

Les scanners automatisés sont efficaces pour repérer les saisies réfléchies et les schémas connus, mais ils ne comprennent pas à quoi sert votre application. Ils ne peuvent pas savoir qu'un code de réduction ne doit s'appliquer qu'une fois, qu'une facture en brouillon ne doit pas être payable, ou qu'un agent du support doit voir les tickets sans pouvoir modifier la facturation. Ces règles sont propres à votre activité, et leur violation est précisément ainsi que se produisent les vrais abus.

Nous consacrons l'essentiel d'un test d'application web à ce côté humain : lire comment chaque fonctionnalité est censée fonctionner, puis vérifier si le serveur l'applique réellement lorsqu'une requête arrive dans le désordre, avec une valeur modifiée, ou depuis le mauvais compte. C'est plus lent qu'une analyse et bien plus utile, car on atteint les problèmes qui coûtent de l'argent et de la confiance plutôt que ceux qu'un outil aurait signalés de toute façon.

Comment fonctionnent les tests d'intrusion d'applications web, étape par étape

Chaque étape produit un résultat clair que vous pouvez relire. Le calendrier est convenu dans votre devis.

1
Périmètre
Application, environnements, rôles et comptes de test convenus par écrit.
2
Carte
Chaque page, requête et rôle répertoriés avant le début des tests.
3
Tester
Tests manuels sur les domaines de l'OWASP et sur votre logique métier.
4
Vérifier
Chaque constat confirmé avec soin, avec des preuves d'impact sans danger.
5
Rapport
Constats, niveaux de risque et corrections que vos développeurs peuvent suivre.
6
Contre-test
Corrections vérifiées et rapport mis à jour.

Les outils, et ce qui détermine votre devis

Le prix dépend de votre projet et est convenu dans votre devis. Voici ce qui le fait varier.

Tests d'intrusion d'applications web : facteurs de prix
Facteur	Pourquoi c'est important
Taille de l'application	Plus de pages, de formulaires et d'endpoints impliquent plus à cartographier et à tester.
Rôles et locataires	Chaque rôle et chaque frontière entre clients multiplie les tests de contrôle d'accès.
Workflows	Les paiements, les validations et les processus à plusieurs étapes demandent des tests de logique soignés.
Environnement	Une copie de préproduction stable accélère les tests ; une production fragile demande plus de précautions.
Accès au code source	Une revue en boîte blanche parallèlement aux tests ajoute de la profondeur et de l'effort.

Tests d'intrusion d'applications web : outils
Domaine	Tools
Proxy de test	Burp Suite, OWASP ZAP, outils de développement du navigateur
Discovery	outils de découverte de contenu, outils de sous-domaines
Support	Postman, scripts sur mesure
Conseils	OWASP WSTG, OWASP ASVS, OWASP Top 10, CVSS

Erreurs courantes à éviter

Ce qui tourne le plus souvent mal, et comment un bon projet l'évite.

Masquer des boutons au lieu de vérifier les permissions
Si le serveur ne vérifie pas chaque requête, quiconque trouve l'adresse peut utiliser la fonction.
Faire confiance aux valeurs venant du navigateur
Les prix, identifiants d'utilisateurs et rôles envoyés par le navigateur peuvent être modifiés ; le serveur doit en décider.
Messages d'erreur trop détaillés
Les traces de pile et les erreurs de base de données donnent aux attaquants une carte de votre système.
Tester avec un seul compte
Sans comptes pour plusieurs utilisateurs et rôles, les problèmes de contrôle d'accès restent cachés.

Questions fréquentes

Avez-vous besoin de notre code source ?

Non, la plupart des tests d'applications web se font en boîte grise avec des comptes de test. L'accès au code source nous permet d'aller plus loin et est utile pour les applications critiques.

Pouvez-vous tester une application monopage développée avec React ou Vue ?

Oui. L'interface s'exécute dans le navigateur, nous nous concentrons donc sur les API qui la soutiennent, là où doivent se prendre les vraies décisions de sécurité.

Testez-vous en production ou en préproduction ?

Dans les deux cas. La préproduction est plus sûre lorsqu'elle reflète fidèlement la production. Si nous testons la production, nous convenons de fenêtres et évitons les actions qui pourraient affecter de vrais clients.

Créerez-vous de vraies commandes ou de vrais e-mails ?

Seulement lorsque cela a été convenu. Nous utilisons des comptes de test et des modes de paiement de test, et nous nettoyons les données de test que nous créons.

Comment évaluez-vous le risque ?

Chaque constat reçoit une note fondée sur la facilité avec laquelle il pourrait être exploité et sur ce qu'un attaquant pourrait obtenir, en utilisant le CVSS lorsqu'il s'y prête, accompagné d'un impact métier en langage clair.

La couverture de l'OWASP Top 10 suffit-elle ?

C'est une base solide. Nous testons aussi votre logique métier spécifique, qu'aucune liste générique ne couvre entièrement.

Pouvez-vous refaire un test après nos corrections ?

Oui, un nouveau test des constats est inclus et le rapport est mis à jour avec les résultats.

Pouvez-vous aussi corriger les problèmes ?

Oui. En tant qu'équipe de développement, nous pouvons mettre en œuvre les corrections ou relire celles de votre équipe avant le nouveau test.

Services associés

Tous les services de cloud, QA et sécurité