Découvrez à quoi ressemble un rapport Agentic Deep Scan web
Une évaluation de 222 pages de VulnBank, une application bancaire volontairement vulnérable, et de son API. Elle montre comment chaque vulnérabilité est prouvée par des requêtes reproductibles et rattachée à sa cause première.
- Cible
- Application web et API VulnBank
- Scan
- Web Agentic Deep Scan
- Longueur
- 222 pages
- Résultat
- Risque global : critique
Réalisé sur une cible de démonstration volontairement vulnérable. Aucune donnée client.
Contenu du rapport
Synthèse
Le risque global et le nombre de vulnérabilités par niveau de gravité, dès les premières pages.
Tableau des vulnérabilités
Chaque vulnérabilité avec son niveau de risque, son statut et une courte description.
Exploits prouvés
Une analyse détaillée de chaque vulnérabilité, avec les requêtes qui l'exploitent et les preuves obtenues.
Comment corriger
La cause première de chaque vulnérabilité et la façon de la corriger, avec des étapes de reproduction à rejouer.
Vulnérabilité annotée
Une vulnérabilité, étape par étape
Comment le rapport mène une vulnérabilité de la cible testée jusqu’au correctif. Chaque étape renvoie à sa page dans le rapport complet.
- Cible
vulnbank.org, une banque de démonstration en ligne
Une application de banque en ligne et son API, volontairement vulnérables et conçues pour la formation à la sécurité, testées en conditions réelles. La synthèse s'ouvre sur le risque global : critique.
Page 2 du rapport - Résultats
57 vulnérabilités, classées par risque
42 vulnérabilités confirmées (21 critiques, 14 élevées, 7 moyennes), plus 12 problèmes potentiels à approfondir et 3 mesures de durcissement.
Page 4 du rapport - Tableau des vulnérabilités
Répertoriée et suivie
Le tableau liste chaque problème avec son niveau de risque, son statut et une courte description. Celui-ci est critique et toujours ouvert.
Page 9 du rapport - Vulnérabilité
Critique : signatures JWT non vérifiées
Le serveur acceptait des jetons d'accès sans vérifier leur signature : n'importe qui pouvait forger un jeton administrateur. Le secret partagé, secret123, était en plus facile à deviner.
Page 75 du rapport - Cause première
Des jetons décodés, jamais vérifiés
Le rapport attribue la faille à un appel à jwt.decode avec la vérification de signature désactivée. Le serveur fait alors confiance à tout ce que contient le jeton, y compris is_admin.
Page 75 du rapport - Preuves
Les requêtes qui le prouvent
Sans jeton, /admin/create_admin répond 401. Avec un jeton forgé et une fausse signature, la même requête crée un compte administrateur, et une autre supprime le compte d'un utilisateur.
Page 76 du rapport - Validation
Chaque tentative dans un tableau
Chaque jeton essayé, sa signature et le résultat, côte à côte. Le champ deleted_by de la réponse reprend l'utilisateur du jeton forgé : le serveur lui a fait confiance.
Page 77 du rapport - Correctif
Changer le secret, vérifier chaque jeton
Remplacer secret123 par un secret aléatoire robuste, vérifier la signature et l'expiration à chaque requête, et charger l'utilisateur depuis la base de données au lieu de faire confiance au jeton.
Page 77 du rapport
Comment l'agent a tranché
Pourquoi c'est un vrai risque
Un scanner signale tout ce qui correspond à une règle. Avant de signaler un problème, l'agent vérifie qu'un indice mène à un vrai dommage et écarte les explications inoffensives. Voici son raisonnement sur une vulnérabilité de vulnbank.org.
Étape 1
Pourquoi la page des transactions répond-elle sans connexion ?
GET /transactions/123456 a renvoyé 200 avec l'historique complet des transactions de ce compte. La requête n'avait ni jeton ni cookie.
Page 51 du rapportÉtape 2
L'endpoint est-il simplement tolérant avec les jetons ?
Un faux jeton Bearer, un faux cookie de session et une clé d'API inventée ont tous reçu le même 200. L'endpoint ignore complètement l'authentification.
Page 53 du rapportÉtape 3
Est-ce que ça marche pour n'importe quel compte ?
Oui. Chaque numéro de compte a renvoyé des données, même les mots admin et test. Le compte test a renvoyé à lui seul 1 499 transactions.
Page 53 du rapportÉtape 4
Pourquoi cela arrive-t-il ?
La route lit le numéro de compte dans l'URL et interroge la base de données avec. Rien ne vérifie que le compte appartient à l'appelant.
Page 52 du rapportÉtape 5
Alors, est-ce un risque ?
Oui, critique. N'importe qui sur Internet peut lire les montants, les dates et les contreparties de n'importe quel client, et parcourir les numéros de compte pour tout récupérer.
Page 52 du rapportÉtape 6
Qu'est-ce qui le corrige ?
Exiger une connexion valide et renvoyer 401 sans elle. Puis vérifier que le compte appartient à l'appelant, et renvoyer 403 sinon. Le rapport liste les requêtes qui confirment la correction.
Page 54 du rapport
Vous voulez ce rapport pour votre propre application ?
Réservez une démo et nous vous présenterons un scan de votre application mobile, de votre application web ou de votre API.