Découvrez à quoi ressemble un rapport Agentic Deep Scan mobile
Le rapport complet et non retouché d'un scan d'AndroGoat, une application Android volontairement vulnérable utilisée pour les formations OWASP. Il montre comment chaque vulnérabilité est reliée au code vulnérable, prouvée et corrigée.
- Cible
- AndroGoat (Android)
- Scan
- Mobile Agentic Deep Scan
- Longueur
- 190 pages
- Résultat
- Risque global : élevé
Cible de formation Android : AndroGoat. Consultez chaque résultat pour connaître la configuration de test et la méthode de reproduction. Aucune donnée client.
Contenu du rapport
Synthèse
Le risque global, le build exact testé 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.
Vulnérabilités au niveau du code
Chaque vulnérabilité présente la cause, le code vulnérable et les preuves d'exploitation.
Validation et correctifs
Une seconde passe confirme chaque vulnérabilité, suivie du correctif recommandé et de la façon de le vérifier.
Vulnérabilité annotée
Une vulnérabilité, étape par étape
Comment le rapport mène une vulnérabilité du build exact qui a été testé jusqu’au correctif. Chaque étape renvoie à sa page dans le rapport complet.
- Build
AndroGoat 1.0 (1), package owasp.sat.agoat
Le rapport identifie l’APK exact testé par son package, sa version et son empreinte SHA-1, avec sa taille et la date du scan.
Page 2 du rapport - Résultats
44 vulnérabilités, classées par risque
34 vulnérabilités confirmées (12 élevées, 16 moyennes, 6 faibles, aucune critique), plus 8 problèmes potentiels à approfondir et 2 mesures de durcissement.
Page 3 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 élevé et toujours ouvert.
Page 4 du rapport - Parcours
Les écrans de stockage non sécurisé de l’application
Les écrans de stockage d’AndroGoat enregistrent le nom d’utilisateur et le mot de passe saisis. L’agent a suivi où chacun les écrit : SharedPreferences, une base SQLite, des fichiers temporaires et la carte SD.
Page 16 du rapport - Vulnérabilité
Élevée : identifiants stockés en clair
Les noms d’utilisateur et mots de passe sont écrits en clair dans les SharedPreferences, une base SQLite et des fichiers temporaires, dont un sur le stockage partagé. Les sauvegardes sont aussi activées.
Page 16 du rapport - Preuve
Où finit le mot de passe
L’application décompilée écrit le mot de passe dans users.xml et dans la base aGoat, et le journalise dans la requête SQL. Une sauvegarde adb copie ces deux fichiers. Le rapport signale les deux chemins de stockage qu’il n’a pas pu tester à l’exécution.
Page 18 du rapport - Correctif
Chiffrer, et garder les identifiants hors du stockage partagé
Désactiver les sauvegardes et chiffrer les données stockées sans attendre. Le correctif durable déplace les identifiants vers EncryptedSharedPreferences, adossé au KeyStore, avec un exemple de code.
Page 19 du rapport - Vérification
Comment confirmer le correctif
Rechercher dans l’application décompilée des identifiants passés en clair aux appels de stockage, et vérifier qu’une sauvegarde adb n’expose plus de fichier d’identifiants lisible.
Page 19 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. Voici son raisonnement sur un indice trouvé dans l'application AndroGoat.
Étape 1
Que fait cette adresse dans l'application ?
Les ressources de l'application contiennent l'adresse d'une base de données Firebase, androgoat-42597.firebaseio.com, dans res/values/strings.xml.
Page 69 du rapportÉtape 2
L'application l'utilise-t-elle vraiment ?
Non. Il n'y a aucune bibliothèque Firebase et aucun code ne lit cette valeur. Une vérification par règles la classerait comme un reste inutilisé et passerait à autre chose.
Page 70 du rapportÉtape 3
La base de données elle-même est-elle ouverte ?
L'agent a envoyé une requête à la base de données sans se connecter. Elle a répondu 200 OK et renvoyé un nom d'utilisateur et un mot de passe.
Page 70 du rapportÉtape 4
Alors, est-ce un risque ?
Oui, élevé. Peu importe que l'application ignore l'adresse : quiconque décompresse l'application peut trouver la base de données et la lire sans compte.
Page 31 du rapportÉtape 5
Comment le corriger ?
Activer Firebase Authentication et les règles de sécurité pour que la lecture de la base de données exige un utilisateur connecté, et retirer l'adresse inutilisée de l'application.
Page 32 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.