Exemple de mission

Pentest Mobile : Application React Native

Startup

5 jours

Android (React Native)

Pentest Mobile

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

Contexte de la mission

Le défi

Contexte

Un éditeur d'application mobile avait besoin d'une validation sécurité avant un lancement majeur.

L'application traitait des données sensibles comme les profils, la géolocalisation et les paiements, sans qu'aucune revue de sécurité ait été réalisée.

Objectifs

Valider la sécurité de l'application avant le lancement majeur
Vérifier la protection des données sensibles (profils, paiements, géolocalisation)
Identifier les failles dans le code et les communications réseau

Déroulement

Découvertes clés

Périmètre testé

Décompilation de l'application et examen du code
Interception du trafic réseau
Tests de l'API backend
Vérification du stockage local des données
Revue des mécanismes de connexion

Méthodologie

Tests appuyés sur le guide OWASP MASTG consacré à l’évaluation de la sécurité des applications mobiles.

Extraction et lecture du code de l'application (décompilation)
Interception du trafic réseau
Analyse du stockage local sur le téléphone

Critique

Un secret du service de paiement intégré à l’application permettait des opérations réservées au serveur

Moyen

Données personnelles et mots de passe stockés sans protection sur le téléphone

Élevé

Aucune limite sur les tentatives de connexion, permettant de deviner les codes d'accès

Critique

En modifiant un identifiant dans l'API, un utilisateur pouvait consulter les données d'autres comptes

Moyen

Contrôle d’accès à une fonction réservée effectué uniquement dans l’application et contournable par appel direct à l’API

Moyen

Journaux de débogage actifs en production, exposant des informations techniques sensibles

Résultats

Bilan et recommandations

Bilan

16 vulnérabilités : 2 critiques, 1 élevée, 6 moyennes, 7 faibles

Parmi les 16 vulnérabilités dont 2 critiques identifiées pendant le test, un défaut de contrôle d’accès permettait de consulter les données d’un autre compte en modifiant un identifiant dans une requête API.

Un secret donnant accès au service de paiement était également récupérable dans l’application, ce qui a nécessité son remplacement puis son déplacement côté serveur.

L’équipe a corrigé les contrôles d’accès de l’API et renforcé le stockage local avant le lancement. Le retest a vérifié les deux failles critiques et les autres points corrigés.

Recommandations

Déplacer les clés d’accès sensibles sur le serveur
Limiter le nombre de tentatives de connexion
Vérifier les droits d’accès côté serveur pour chaque requête API
Retirer les informations sensibles des journaux de production
Obfusquer le code de la version distribuée pour compliquer l’analyse de l’application

Enseignements

Leçons apprises

La séparation des comptes reposait en partie sur les écrans de l’application, ce qui permettait de contourner cette restriction par un appel direct à l’API.
La lecture du code a révélé le secret de paiement embarqué, qui a été remplacé puis déplacé côté serveur, avec une obfuscation retenue en complément pour compliquer l’analyse des prochaines versions.
Les journaux de débogage exposaient des informations sensibles inutiles en production, dont la suppression a été intégrée à la préparation des versions distribuées.

Continuité

Prochaines étapes

Pentest de l'API backend approfondi
Ajouter des tests de non-régression sur les contrôles d’accès de l’API
Intégration de tests de sécurité automatisés dans le cycle de développement (accompagnement cybersécurité)