La checklist du pentest d’applications mobiles : OWASP MASVS en pratique

Donnez-moi un APK et cinq minutes, et je vous rendrai en général quelque chose que les développeurs ne voulaient pas voir livré. On le décompresse, on le passe dans jadx, on grep le code source décompilé à la recherche de password, secret ou api_key, et on regarde les résultats défiler. Un token codé en dur ici. Un nom d’hôte de staging qui répond encore là. Un TODO d’un sprint dont personne ne se souvient l’avoir écrit.

C’est là que commencent bon nombre de tests d’intrusion d’applications mobiles, et plus souvent qu’on ne le voudrait, c’est aussi de là que vient la première vraie trouvaille. Le client tourne sur du matériel qui ne vous appartient pas. Un attaquant peut démonter le binaire sur son propre établi, à son propre rythme, sans limitation de débit et sans que personne ne surveille. Les réflexes du web ne survivent pas au contact de cette réalité.

Nous ancrons chaque mission dans le standard OWASP Mobile Application Security Verification Standard, MASVS, et nous en faisons une checklist que nous déroulons contre de vrais builds Android et iOS. Voici comment cela se passe concrètement.

Points clés à retenir

• Les tests d’intrusion d’applications mobiles associent l’analyse statique du binaire décompilé à l’analyse dynamique d’une application en cours d’exécution et instrumentée, car le client est entièrement entre les mains de l’attaquant.
• OWASP MASVS regroupe les contrôles en stockage, cryptographie, authentification, réseau, interaction avec la plateforme, qualité du code et résilience ; l’OWASP MASTG vous fournit des cas de test concrets pour chacun.
• Les trouvailles sérieuses que nous rapportons le plus souvent sont le stockage local de données non sécurisé, la cryptographie mal employée et les failles d’autorisation côté backend qui apparaissent une fois le certificate pinning contourné.
• Le certificate pinning ralentit un testeur. Il ne rend pas une application sûre. Si le serveur fait confiance au client, contourner le pin ne fait que révéler les vraies failles en dessous.
• MASVS définit des niveaux de vérification (L1 socle de base, L2 défense en profondeur, R résilience) : calibrez donc le test selon le risque réel de l’application plutôt que de tout tester à la même profondeur.

Qu’est-ce que MASVS, et pourquoi y adosser un pentest mobile ?

MASVS est la réponse d’OWASP à une question simple : que devrait réellement faire une application mobile sûre ? C’est la colonne vertébrale de toute mission sérieuse de tests d’intrusion d’applications mobiles. Les exigences sont réparties en groupes de contrôles – stockage (MASVS-STORAGE), cryptographie (MASVS-CRYPTO), authentification et gestion de session (MASVS-AUTH), communication réseau (MASVS-NETWORK), interaction avec la plateforme (MASVS-PLATFORM), qualité du code (MASVS-CODE) et résilience face à la rétro-ingénierie (MASVS-RESILIENCE).

Son compagnon, l’OWASP Mobile Application Security Testing Guide (MASTG), est là où le standard prend toute sa valeur. MASVS dit que l’application “ne devrait pas stocker de données sensibles en clair”. MASTG vous dit quels fichiers extraire, quelles API laissent fuiter des données et comment le prouver. Nous utilisons MASVS comme carte de couverture pour que rien ne soit oublié, et MASTG comme mode d’emploi pour chaque contrôle.

Une chose mérite d’être dite clairement : une checklist est un plancher, pas un plafond. Nous déroulons les catégories MASVS pour garantir la couverture, puis nous passons le reste de la mission à traquer la logique propre à l’application qu’aucun standard ne pourrait prévoir. Les bugs intéressants vivent presque toujours dans la logique métier et le backend, pas dans le fait que l’application coche une case générique.

Comment tester une application mobile ? Statique plus dynamique

Chaque mission, ce sont deux passes sur la même cible : l’application au repos, et l’application pendant qu’elle tourne. Sautez l’une des deux et vous manquez la moitié du tableau.

Analyse statique : lire le binaire

Sur Android, on décompile d’abord. apktool vous donne le manifeste et les ressources ; jadx retransforme le DEX en Java lisible. Sur iOS, vous travaillez avec un IPA déchiffré, des class dumps et l’Info.plist. Le but de la passe statique est de comprendre l’application avant de l’exécuter, et d’attraper les choses qui n’apparaissent jamais dans le trafic.

Une ouverture typique sur Android :

apktool d target.apk -o target_src
jadx -d target_out target.apk

# hunt for obvious secrets and dangerous config
grep -rniE "api[_-]?key|secret|password|token|BEGIN RSA" target_out/
grep -rn "usesCleartextTraffic" target_src/AndroidManifest.xml

Ensuite, on lit l’AndroidManifest à la recherche de composants exportés : activités, services, broadcast receivers et content providers marqués android:exported="true" sans garde de permission. Une activité exportée qui reçoit un intent et charge une URL dans une WebView est un chemin classique vers le task hijacking ou l’injection WebView. Sur iOS, la chasse équivalente porte sur les schémas d’URL personnalisés et les Universal Links déclarés dans le plist, car ce sont eux aussi des points d’entrée atteignables par un attaquant.

La configuration réseau compte ici aussi. usesCleartextTraffic="true", ou un network_security_config.xml permissif qui fait confiance aux CA ajoutées par l’utilisateur, vous indique que le trafic en clair ou l’interception sont envisageables avant même d’ouvrir un proxy.

Analyse dynamique : l’exécuter et observer

L’analyse dynamique nécessite un appareil Android rooté ou un iPhone jailbreaké, ou leurs équivalents en émulateur. Notre instrumentation de prédilection est Frida, avec Objection par-dessus. Frida hooke les méthodes à l’exécution, extrait les arguments et réécrit les valeurs de retour. Objection nous offre des gains rapides – lister les entrées du keychain, extraire les SharedPreferences, désactiver les vérifications de pin courantes – sans écrire à la main un hook pour chacune.

Nous faisons passer tout le trafic par Burp Suite. Dès que l’application dialogue avec son backend, le travail spécifique au mobile s’arrête en grande partie et le test d’API classique commence : contrôles d’autorisation, IDOR sur les identifiants d’objets, mass assignment, rejeu des requêtes d’un autre utilisateur. Obtenir une vue propre de ce trafic est la priorité numéro un, et c’est précisément pourquoi le certificate pinning compte autant dans le processus.

Quelles sont les trouvailles les plus fréquentes en pentest d’application mobile ?

La même poignée de problèmes revient d’une mission à l’autre. Ils se rattachent proprement aux catégories MASVS, ce qui est un bon indice que le standard a été bâti sur de vraies douleurs plutôt que sur de la théorie.

Stockage de données non sécurisé (MASVS-STORAGE)

C’est la trouvaille que nous rapportons le plus. Les applications mettent en cache bien plus que ne l’imaginent les développeurs. Sur Android, on récupère le bac à sable et on parcourt les XML de SharedPreferences, les bases SQLite et les fichiers du répertoire de données interne :

adb shell run-as com.example.app ls -la /data/data/com.example.app/
adb shell run-as com.example.app cat shared_prefs/*.xml

Des jetons de session. Des identifiants complets. Des données personnelles (PII). Parfois des données de paiement, posées en clair dans les SharedPreferences ou dans une table SQLite non chiffrée. Sur iOS, la même classe de bug apparaît dans NSUserDefaults, les fichiers plist, les stores Core Data et les éléments du Keychain enregistrés avec une classe d’accessibilité faible comme kSecAttrAccessibleAlways. Tout ce qui est lisible sur un appareil perdu ou infecté par un malware constitue une exposition réelle, et cela correspond à CWE-312, stockage en clair d’informations sensibles.

Cryptographie faible ou mal employée (MASVS-CRYPTO)

La catégorie cryptographie concerne rarement des mathématiques cassées. Elle concerne le mauvais usage. Des clés codées en dur tirées directement du source décompilé. Le mode ECB, où des blocs de texte en clair répétés laissent transparaître la structure dans le chiffré – ce choix d’algorithme cassé, c’est CWE-327. Des IV statiques ou nuls. Un “chiffrement” maison qui se révèle n’être que du Base64 avec quelques étapes en plus, et Base64 est de l’encodage, pas de la protection.

Frida est parfait pour le confirmer en direct. Hookez la mise en place du cipher et affichez la clé et l’IV pendant que l’application tourne :

Java.perform(function () {
  var Cipher = Java.use("javax.crypto.Cipher");
  Cipher.init.overload("int", "java.security.Key").implementation = function (mode, key) {
    console.log("[cipher] alg=" + this.getAlgorithm() +
                " key=" + Java.use("android.util.Base64").encodeToString(key.getEncoded(), 0));
    return this.init(mode, key);
  };
});

Quand la clé qui “protège” vos données s’affiche dans la console au lancement de l’application, le débat sur la solidité théorique est clos.

Failles d’autorisation et de session côté backend (MASVS-AUTH)

Une fois le trafic visible, c’est le serveur qui porte la confiance, et c’est là que se cachent les bugs à forte sévérité. Des jetons qui n’expirent jamais. Des identifiants de session prévisibles. Des décisions d’autorisation prises côté client au lieu du serveur. Si l’application masque un bouton admin mais que l’API répond de bon cœur à l’appel admin depuis un compte normal, c’est une faille critique, et aucun durcissement côté client ne la corrige.

Comment contourner le certificate pinning ?

Vous contournez le pinning en hookant le code qui effectue la vérification du pin et en le forçant à réussir – généralement avec Frida ou Objection – pour que votre CA de proxy soit de nouveau approuvée. Objection propose une commande en une ligne :

objection -g com.example.app explore
# then, in the Objection prompt:
android sslpinning disable

Pour les applications dotées d’une implémentation de pinning maison ou de vérifications en code natif, le bypass générique échoue et vous basculez sur un script Frida ciblé qui hooke le TrustManager précis, le CertificatePinner d’OkHttp ou le chemin natif SSL_CTX_set_custom_verify. Sur iOS, vous hookez généralement TrustKit ou la logique d’évaluation de confiance propre à l’application autour de SecTrustEvaluate.

Voici la partie opinion. Le pinning est un ralentisseur, pas un contrôle. Il augmente le coût pour un attaquant occasionnel et fait gagner du temps face à l’outillage automatisé, ce qui est réellement utile et vaut la peine d’être mis en place. Mais si vaincre le pin révèle une API à l’autorisation cassée, le pinning n’était que cosmétique. Nous testons chaque application comme si le pinning était déjà vaincu, car un attaquant motivé disposant du binaire et d’un appareil rooté finira par en venir à bout. MASVS classe le pinning sous la résilience pour exactement cette raison : c’est de la défense en profondeur, pas un substitut à un backend qui applique ses propres règles.

Comment corriger ces problèmes ?

Surtout en respectant la plateforme. Utilisez le stockage sécurisé fourni par l’OS plutôt que de bricoler le vôtre : Android Keystore et EncryptedSharedPreferences via Jetpack Security, et le Keychain iOS avec une classe d’accessibilité sensée comme kSecAttrAccessibleWhenUnlockedThisDeviceOnly. Ne rangez jamais de secrets à longue durée de vie dans les SharedPreferences ou NSUserDefaults.

Pour la cryptographie, tournez-vous vers des bibliothèques de haut niveau éprouvées plutôt que vers des appels de cipher bruts. Tink de Google est un bon choix par défaut, car il fait de l’option sûre l’option facile. N’embarquez pas de clés dans l’application ; dérivez-les ou provisionnez-les à l’exécution et gardez les vraies décisions de confiance sur le serveur. Traitez le client comme non fiable, de bout en bout – chaque contrôle d’autorisation et de validation qui compte doit être appliqué côté serveur, car le client mobile peut être altéré et le sera. Ajoutez le pinning et l’anti-tamper comme couches supplémentaires une fois les fondamentaux en place, pas avant.

Comment CyberXplore vous aide

Notre service de test d’intrusion d’applications mobiles déroule contre vos builds Android et iOS l’intégralité de la méthodologie alignée sur MASVS décrite ici : analyse statique du binaire décompilé, analyse dynamique sur appareils instrumentés, contournement du pinning et examen sans concession des API backend sur lesquelles s’appuie l’application. Vous obtenez un rapport qui classe les trouvailles selon leur impact métier réel, avec des étapes de reproduction qu’un développeur peut suivre et un retest une fois les correctifs déployés, afin que la correction soit vérifiée et pas seulement annoncée. Vous préparez une revue de l’app store, un questionnaire de sécurité client ou un audit de conformité ? Nous alignons la mission sur le bon niveau de vérification MASVS. Demandez un devis et parlez-nous de votre application ; nous en définirons le périmètre honnêtement.

FAQ

Combien de temps dure un test d’intrusion d’application mobile ?

Une application ciblée sur une seule plateforme représente en général une à deux semaines de test, selon le nombre de fonctionnalités, la taille de la surface d’API et le fait que Android et iOS soient tous deux dans le périmètre. Les applications à forte logique backend prennent plus de temps, car l’essentiel des trouvailles sérieuses réside dans l’autorisation côté serveur, et c’est là que partent les heures une fois le trafic visible.

Faut-il le code source pour tester une application mobile ?

Non. Nous travaillons très bien en mode boîte noire à partir du seul APK ou IPA compilé, puisque la décompilation fait de toute façon partie du travail. Cela dit, un test en boîte grise où vous partagez le code source et des comptes de test trouve davantage et plus vite, car nous consacrons les heures de test à de vrais bugs plutôt qu’à de la rétro-ingénierie. Nous recommandons la boîte grise pour le meilleur rapport qualité-prix.

Quelle est la différence entre MASVS et MASTG ?

MASVS est le standard : il définit les exigences de sécurité qu’une application mobile devrait respecter, regroupées en catégories et niveaux de vérification. MASTG est le guide de test : il donne aux testeurs des techniques concrètes, l’usage des outils et des cas de test pour vérifier chaque exigence. En pratique, nous utilisons MASVS comme checklist de couverture et MASTG comme manuel de procédure.

Le certificate pinning rend-il mon application sûre ?

Non. Le pinning est un contrôle de résilience qui ralentit l’interception et les attaques automatisées, ce qui vaut la peine, mais un testeur déterminé disposant d’un appareil rooté le contournera. Il ne fait rien contre le stockage local non sécurisé, la cryptographie faible ou l’autorisation backend cassée. Considérez-le comme une couche posée sur une application déjà sûre sans lui.

À quelle fréquence faut-il pentester une application mobile ?

Au moins une fois par an, et après tout changement significatif tel qu’un nouveau flux d’authentification, une fonctionnalité de paiement ou une intégration backend majeure. Les applications mobiles sortent vite, et chaque release peut réintroduire d’anciens problèmes ou ajouter de nouvelles surfaces d’attaque, si bien qu’un test ponctuel ne vous renseigne que sur le build testé. Beaucoup d’équipes associent un test complet annuel à des retests plus légers sur les releases majeures.