Chapitre 14 : Mobile Application Pentesting

OWASP MASVS / MASTG

Sécurité des Applications Android & iOS

En s'appuyant sur le référentiel OWASP MASVS/MASTG : analyse statique, analyse dynamique avec Frida, contournement du certificate pinning, et les 8 catégories de sécurité mobile à connaître.

1. Android & iOS

Taxonomie des apps mobiles et mise en place d'un labo de test sur les deux plateformes.

2. Analyse Statique & Dynamique

Décompilation, secrets codés en dur, instrumentation avec Frida.

3. Outils de Référence

MobSF, Objection, Burp Suite — pour automatiser et approfondir chaque test.

Introduction — Pourquoi le Mobile est Différent

Concepts

Spécificités du Mobile

Chaque application tourne dans un bac à sable (sandbox) isolé, avec un système de permissions explicite propre à la plateforme.
Le code de l'application est physiquement présent sur l'appareil de l'utilisateur — il peut donc être décompilé et analysé, contrairement à une application web dont la logique reste côté serveur.

Une Hypothèse Souvent Fausse

De nombreux développeurs codent en dur des clés API, secrets OAuth ou URLs de base de données en partant du principe que "personne ne décompilera l'application".
Des outils comme jadx rendent cette extraction triviale — c'est l'une des découvertes les plus fréquentes en pentest mobile.

Le Référentiel OWASP MASVS

MASVS

Concepts

MASVS (Mobile Application Security Verification Standard) définit quoi vérifier : une liste d'exigences de sécurité organisées par catégorie.
MASTG (Mobile Application Security Testing Guide) explique comment vérifier chaque exigence, avec des cas de test concrets pour Android et iOS.
Utilisé aussi bien par les pentesters indépendants que par les grandes plateformes mobiles elles-mêmes pour structurer leurs propres exigences de sécurité.

Les 8 Catégories MASVS

STORAGEStockage des données

CRYPTOCryptographie

AUTHAuthentification & autorisation

NETWORKCommunication réseau

PLATFORMInteraction avec la plateforme

CODEQualité du code

RESILIENCERésilience au reverse engineering

PRIVACYVie privée

Taxonomie des Applications Mobiles

Concepts

Trois Grandes Familles

Natives : écrites directement pour la plateforme (Kotlin/Java sur Android, Swift/Objective-C sur iOS) — performance maximale, mais code spécifique à chaque OS.
Web/Hybrides : reposent en grande partie sur une WebView affichant du contenu web packagé — héritent des risques web (chapitre 13) en plus des risques mobiles.
Cross-platform : React Native, Flutter... un seul code source compilé pour les deux plateformes — nécessite des outils de décompilation spécifiques à chaque framework.

Mise en Place du Labo — Android (ADB)

Environnement de Test

Concepts

ADB (Android Debug Bridge) est l'outil de référence pour interagir avec un appareil ou un émulateur Android depuis un poste de travail.
Un appareil rooté (ou un émulateur) est généralement nécessaire pour accéder aux données privées de l'application testée.

Commandes de Base

adb devices
adb shell
adb install application.apk
adb pull /sdcard/fichier.txt ./
adb logcat

Mise en Place du Labo — iOS

Environnement de Test

Concepts

Contrairement à Android, un appareil iOS jailbreaké reste généralement nécessaire pour une analyse dynamique complète (accès filesystem, injection Frida).
Les outils diffèrent, mais la méthodologie MASTG reste la même sur les deux plateformes.

Outils Équivalents

# Installer / lister les applications
ideviceinstaller -l

# Extraire les symboles et classes Objective-C/Swift
class-dump Application

# Inspecter un binaire Mach-O
otool -L Application

Obtenir & Décompiler une Application

Analyse Statique

Démo — Android (APK)

# Extraire l'APK installé depuis l'appareil
adb shell pm path com.exemple.application
adb pull /data/app/com.exemple.application/base.apk

# Désassembler les ressources et le manifeste
apktool d base.apk -o app_decompile

# Décompiler le code Java/Kotlin lisible
jadx -d app_source base.apk

Analyse Statique — Secrets Codés en Dur

MASVS-STORAGE / MASVS-CODE

Concepts

Clés API, secrets OAuth, URLs de base de données Firebase, clés d'accès cloud — souvent laissés en clair dans le code compilé.
Le développeur suppose à tort que la compilation protège ces informations.

Démo

# Rechercher des motifs sensibles dans le code décompilé
grep -r "api_key\|secret\|firebaseio\|AKIA" app_source/

# Recherche ciblée sur les chaînes de caractères du binaire
strings base.apk | grep -i "password\|token"

Stockage Local Non Sécurisé

MASVS-STORAGE

Concepts

La vulnérabilité mobile la plus fréquemment rencontrée en pentest : des données sensibles (tokens, informations personnelles, données financières) stockées en clair, lisibles par toute application sur un appareil rooté.
Emplacements à vérifier : SharedPreferences, bases SQLite, fichiers internes/externes, journaux applicatifs, cache clavier, captures d'écran automatiques.

Démo

# Explorer le répertoire de données de l'application
adb shell run-as com.exemple.application ls -la /data/data/com.exemple.application

# Extraire et lire une base SQLite locale
adb pull /data/data/com.exemple.application/databases/app.db
sqlite3 app.db "SELECT * FROM utilisateurs;"

Analyse Dynamique avec Frida

Frida

Concepts

Framework d'instrumentation dynamique : permet d'injecter du code JavaScript dans un processus en cours d'exécution pour observer ou modifier son comportement en temps réel.
Objection est une surcouche à Frida qui simplifie les tâches courantes de pentest mobile sans écrire de script à chaque fois.

Démo

# Attacher Objection à l'application en cours d'exécution
objection -g com.exemple.application explore

# Lister les classes chargées en mémoire
android hooking list classes

# Hooker une méthode spécifique
android hooking watch class_method \
  com.exemple.application.LoginActivity.checkPassword

Contourner le Certificate Pinning

MASVS-NETWORK

Concepts

Le certificate pinning empêche l'application de faire confiance à un certificat autre que celui attendu — ce qui bloque l'interception du trafic, même via un proxy comme Burp Suite.
Contourner ce mécanisme est un prérequis pour toute analyse dynamique du trafic réseau mobile.

Démo

# Avec Objection : désactiver le pinning SSL à la volée
objection -g com.exemple.application explore
android sslpinning disable

Intercepter le Trafic Réseau Mobile

MASVS-NETWORK

Concepts

Une fois le pinning contourné, le principe rejoint celui du proxy web déjà vu au chapitre 13 (Burp Suite) : configurer le Wi-Fi de l'appareil ou de l'émulateur pour passer par le proxy, puis installer le certificat CA de Burp comme certificat de confiance sur l'appareil.
À vérifier : présence de trafic en clair (HTTP), TLS mal configuré, absence de vérification correcte du certificat serveur.

MASVS-AUTH — Authentification Locale

MASVS-AUTH

Concepts

Concerne l'authentification biométrique (empreinte, reconnaissance faciale) et son intégration avec les clés cryptographiques de l'appareil.
Points de test clés : un repli (fallback) vers une authentification non-biométrique est-il autorisé pour des actions sensibles ? Les clés cryptographiques sont-elles invalidées lors de l'enregistrement d'une nouvelle empreinte ?
Une authentification biométrique mal implémentée peut parfois être contournée directement au niveau applicatif, sans toucher au capteur biométrique lui-même.

MASVS-PLATFORM — Composants Inter-Process

MASVS-PLATFORM

Concepts (Android)

Activities, Services et Broadcast Receivers peuvent être exportés (accessibles à d'autres applications) — s'ils exposent une fonctionnalité sensible sans protection, c'est une voie d'attaque directe.
Les Deep Links non validés peuvent permettre à une autre application malveillante de déclencher des actions inattendues.

WebViews — Un Risque Récurrent

Une WebView chargeant du contenu non fiable, avec JavaScript activé et un accès aux ressources locales, peut exposer des fonctionnalités natives sensibles au contenu web affiché.

MASVS-RESILIENCE — Anti-Reverse Engineering

MASVS-RESILIENCE

Concepts

Regroupe les mécanismes destinés à ralentir l'analyse et la modification de l'application : détection root/jailbreak, détection de débogueur, détection d'émulateur, obfuscation du code.
Le rôle du pentester est double : vérifier que ces protections existent réellement (une application sensible sans aucune détection root est un constat en soi), puis tenter de les contourner pour valider qu'elles ne sont pas juste symboliques.
L'obfuscation ralentit l'analyse mais ne remplace jamais une architecture de sécurité solide — c'est une couche défensive supplémentaire, pas une protection à elle seule.

Automatiser avec MobSF

MobSF

Concepts

Mobile Security Framework (MobSF) automatise une bonne partie des vérifications de référence (niveau baseline) du MASVS, pour Android et iOS.
Ne remplace pas l'analyse manuelle, mais permet de couvrir rapidement les points de contrôle standards avant d'approfondir.

Démo

# Lancer l'interface MobSF localement
docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf

# Puis uploader l'APK/IPA via l'interface web
# et consulter le rapport MASVS généré automatiquement

Méthodologie Complète — Mobile Pentest

Méthodologie

Démarche Type

1. Reconnaissance : obtenir l'APK/IPA, identifier la taxonomie (native, hybride, cross-platform).
2. Analyse statique : décompiler, rechercher les secrets codés en dur, vérifier la configuration du stockage local.
3. Analyse dynamique : instrumenter avec Frida/Objection, contourner le certificate pinning, intercepter le trafic réseau.
4. Tests par catégorie MASVS : authentification locale, composants IPC, résilience au reverse engineering.
5. Automatisation complémentaire : MobSF pour couvrir rapidement la baseline avant de creuser manuellement.
6. Documentation : chaque constat rattaché à une catégorie MASVS précise, avec preuve reproductible.

Modèle Mental — Une Application Mobile est un Système Distribué

Méthodologie

Objectif : ne pas limiter le pentest au fichier APK/IPA. L'application mobile est un client qui dialogue avec des API, des services d'identité, du stockage local et les mécanismes de sécurité de l'OS.

1 — App

Code, ressources, manifeste, permissions, logique locale.

→

2 — OS

Sandbox, keystore/keychain, IPC, permissions, biométrie.

→

3 — Réseau

TLS, pinning, API, tokens, WebSockets, DNS.

→

4 — Backend

Authentification, autorisation, logique métier, données.

Conséquence : une faiblesse locale n'est pas automatiquement critique. Il faut déterminer ce qu'elle permet réellement de compromettre et si le backend vérifie correctement les opérations sensibles.

Android — Structure d'un APK

Android

Éléments à connaître

AndroidManifest.xml : permissions, composants, intent filters, configuration.
classes.dex : bytecode Dalvik/ART contenant la logique applicative.
res/ & assets/ : ressources, fichiers embarqués, configurations éventuelles.
lib/ : bibliothèques natives .so.
META-INF/ : informations liées à la signature du package.

Premier tri

unzip -l app.apk
aapt dump badging app.apk
apkanalyzer manifest permissions app.apk
jadx-gui app.apk

À rechercher : package name, min/target SDK, permissions, exported components, URLs, bibliothèques natives et mécanismes de protection.

Android Manifest — Surface d'Attaque

MASVS-PLATFORM

Points de contrôle

Permissions réellement nécessaires vs permissions excessives.
Activities, Services, Receivers et Providers exposés.
Intent filters et deep links associés aux composants.
Configuration réseau et paramètres de sécurité déclarés.

Inspection

apktool d app.apk -o app_dec
grep -R "android:exported" app_dec/AndroidManifest.xml
grep -R "android.permission" app_dec/AndroidManifest.xml
grep -R "http://" app_dec/

Attention : un composant exporté n'est pas forcément une vulnérabilité. Le test doit vérifier si une application externe peut réellement déclencher une opération sensible sans contrôle d'accès approprié.

iOS — Architecture et Artefacts à Examiner

iOS

IPA

Archive contenant l'application et ses ressources. Son inspection permet d'identifier la structure et les artefacts embarqués.

Mach-O

Format binaire principal. L'analyse des imports, symboles et chaînes aide à comprendre les capacités du binaire.

Info.plist

Configuration de l'application : URL schemes, permissions déclarées, capacités et paramètres d'exécution.

Principe : sur iOS comme sur Android, commencer par comprendre la surface exposée avant de chercher à contourner une protection.

Reconnaissance — Identifier le Framework Mobile

Recon

Pourquoi l'identifier ?

Les artefacts disponibles et les techniques de décompilation varient selon le framework.
Flutter, React Native, Xamarin/.NET et applications natives n'exposent pas exactement les mêmes structures.
Le framework peut révéler les endroits où chercher la configuration, les endpoints ou la logique métier.

Indices pratiques

unzip -l app.apk | grep -Ei "flutter|react|xamarin"
strings app.apk | grep -Ei "flutter|reactnative"
find app_dec -type f | head -50

NativeFlutterReact Native.NETWebView

Analyse Statique — Endpoints, Secrets et Configuration

Static Analysis

Recherche structurée

URLs et domaines API.
Clés publiques, tokens, identifiants de test.
Configuration Firebase/cloud et services tiers.
Flags de debug et environnements de développement.
Certificats, fingerprints ou configuration TLS embarquée.

Exemples

grep -RniE "https?://|api[_-]?key|secret|token" app_source/
strings classes.dex | grep -Ei "https?://|token|secret"
find . -type f \\( -name "*.json" -o -name "*.xml" \\)

Validation : une chaîne ressemblant à un secret n'est pas nécessairement exploitable. Vérifier son rôle, sa validité, ses privilèges et sa portée.

Stockage Local — Où Chercher les Données Sensibles

MASVS-STORAGE

Emplacement	Exemples	Risque à examiner
Préférences	SharedPreferences / NSUserDefaults	Tokens, flags, identifiants
Bases locales	SQLite / Core Data	Données métier, PII, cache
Fichiers	Internal / External storage	Exports, backups, fichiers temporaires
Logs	Logcat / journaux applicatifs	Secrets, tokens, données utilisateur
Presse-papiers	Clipboard	Codes, tokens ou données copiées

À distinguer : présence d'une donnée sensible, accessibilité par une autre application, accessibilité après compromission/root et absence de chiffrement sont des constats différents.

Android Keystore & iOS Keychain

Cryptographie

Android Keystore

Permet de gérer des clés cryptographiques protégées par le système.
Le test porte notamment sur la façon dont l'application utilise les clés et sur les données réellement stockées hors du mécanisme sécurisé.

iOS Keychain

Stockage sécurisé prévu pour certains secrets et identifiants.
Vérifier les attributs de protection et le contexte dans lequel les données peuvent être accessibles.

Point essentiel : utiliser un coffre système ne suffit pas si l'application place simultanément le secret en clair dans une base SQLite, un fichier de configuration ou les logs.

Analyse Dynamique — Observer le Comportement Réel

Dynamic Analysis

Instrumenter

Frida / Objection

→

Déclencher

Login, paiement, upload, changement de profil...

→

Observer

Arguments, retours, appels réseau, fichiers

→

Valider

Déterminer l'impact réel

Outils complémentaires

frida-ps, frida-trace, Objection, Burp Suite, ADB/logcat et les outils de debugging de la plateforme.

Frida — Ce qu'on Cherche à Observer

Instrumentation

Authentification

Arguments des fonctions de login, génération/validation de tokens, réponses du backend.

Cryptographie

Entrées/sorties de fonctions cryptographiques et utilisation des clés.

Logique métier

Conditions locales, contrôles de rôle ou décisions prises uniquement côté client.

Approche : instrumenter pour comprendre et confirmer une hypothèse, pas uniquement pour modifier le comportement de l'application.

Certificate Pinning — Comprendre Avant de Contourner

MASVS-NETWORK

Fonctionnement

Le TLS authentifie normalement le serveur via la chaîne de confiance.
Le pinning ajoute une contrainte supplémentaire : l'application attend une identité cryptographique spécifique.
Un proxy d'interception avec un certificat différent peut donc être refusé.

Validation

Observer si l'application accepte le certificat du proxy dans un environnement de test.
Si elle refuse, identifier le mécanisme de pinning avant de choisir une technique d'instrumentation.
Documenter le comportement avant/après contournement.

Analyse Réseau — Que Chercher dans Burp ?

Network

Requêtes

Endpoints, méthodes HTTP et paramètres.
Headers d'authentification et cookies.
Identifiants d'objet, rôles et paramètres métier.
Upload/download et formats de données.

Réponses

Codes HTTP et messages d'erreur.
Données sensibles retournées inutilement.
Tokens, identifiants internes, informations de debug.
Contrôles d'autorisation réellement appliqués côté serveur.

Authentification Mobile — Ne Pas Confondre UI et Sécurité

MASVS-AUTH

Un bouton ou écran « admin » masqué dans l'application n'est pas un contrôle d'autorisation. La décision de sécurité doit être appliquée par le backend pour les opérations sensibles.

Tests côté client

Modifier les valeurs locales et observer si elles changent uniquement l'interface.
Examiner les contrôles de rôle et flags présents dans le code.
Vérifier les mécanismes de verrouillage local.

Tests côté serveur

Rejouer les requêtes avec différents comptes.
Modifier les identifiants d'objets.
Vérifier que le serveur refuse réellement les opérations non autorisées.

Tokens & Sessions — Cycle de Vie

AUTH / NETWORK

Login

Obtention du token/session

→

Stockage

Keychain/Keystore ou stockage applicatif

→

Usage

Authorization header / cookie

→

Expiration

Refresh, révocation, logout

Points de test : expiration, révocation après logout, renouvellement, exposition dans les logs, stockage local et réutilisation d'un token hors contexte.

IPC Android — Activities, Services, Receivers, Providers

MASVS-PLATFORM

Activity

Interface ou point d'entrée. Tester les paramètres reçus via Intent et les contrôles d'accès.

Service

Composant exécutant des tâches en arrière-plan. Vérifier son exposition et ses permissions.

Receiver

Réagit à des événements/broadcasts. Examiner les broadcasts accessibles et les données consommées.

Question centrale : « Une autre application peut-elle appeler ce composant et déclencher une action sensible ? »

Deep Links & URL Schemes

PLATFORM

Surface de test

Schémas personnalisés et liens universels/app links.
Paramètres transmis dans l'URL.
Navigation vers des écrans privilégiés.
Objets ou actions référencés par identifiant.

Android — exemple de déclenchement

adb shell am start \
  -a android.intent.action.VIEW \
  -d "myapp://profile?id=123"

Observer si l'application valide l'origine, le contexte d'authentification et les paramètres reçus.

WebView — Pont entre Web et Mobile

PLATFORM / NETWORK

Questions de sécurité

Quelle URL la WebView peut-elle charger ?
JavaScript est-il activé ?
Des interfaces natives sont-elles exposées au contenu web ?
Les liens externes sont-ils contrôlés ?

Risque

Une WebView mal configurée peut transformer une faiblesse Web en accès à des fonctionnalités natives. Tester séparément la surface Web et le bridge natif.

Résilience — Root, Debugger, Emulator et Intégrité

RESILIENCE

Contrôles à identifier

Détection root/jailbreak.
Détection debugger.
Détection émulateur.
Vérification d'intégrité du binaire/environnement.
Obfuscation et anti-tampering.

Deuxième étape

Après identification, déterminer si le contrôle protège réellement une fonction sensible ou s'il ne fait qu'afficher un avertissement local.

Une protection contournable n'implique pas automatiquement une vulnérabilité critique : l'impact dépend de ce que le contournement permet ensuite.

MobSF — Utiliser l'Automatisation Correctement

MobSF

Scan

Obtenir une baseline rapide

→

Tri

Écarter les observations non pertinentes

→

Validation

Reproduire manuellement

→

Impact

Établir le scénario réel

Règle : un finding automatisé est une piste, pas une preuve finale. Toujours vérifier le contexte, l'exploitabilité et l'impact.

Checklist d'Analyse Statique

STATIC

Identifier le package/bundle.
Identifier le framework.
Analyser le manifeste/configuration.
Lister les permissions.
Rechercher les endpoints.
Rechercher secrets et tokens.
Examiner les certificats/config TLS.
Analyser les bibliothèques tierces.
Identifier les composants exportés.
Examiner deep links.
Rechercher WebViews.
Inspecter les mécanismes anti-debug/root.
Examiner les données embarquées.
Identifier les environnements de test/debug.

Checklist d'Analyse Dynamique

DYNAMIC

Installer l'application.
Observer le comportement au premier lancement.
Observer les logs.
Capturer le trafic réseau.
Tester login/logout.
Tester expiration et renouvellement de session.
Tester les fonctions sensibles.
Observer les fichiers créés.
Observer les bases locales.
Tester les deep links.
Tester les composants IPC.
Examiner les WebViews.
Instrumenter les fonctions pertinentes.
Valider les protections de résilience.

De la Découverte au Finding

Validation

Observation

Ex. token trouvé dans un fichier.

→

Hypothèse

Le token est-il sensible ?

→

Validation

Est-il encore valide et utilisable ?

→

Impact

Quelles données/actions sont accessibles ?

Rapport : conserver l'artefact, le contexte, les étapes de reproduction et une preuve minimale permettant de démontrer le risque sans exposer inutilement des secrets.

Erreurs Classiques en Mobile Pentest

Lessons Learned

À éviter

Se limiter au scan MobSF.
Considérer toute clé trouvée comme immédiatement exploitable.
Tester uniquement le client sans vérifier le backend.
Confondre root/emulator detection et contrôle de sécurité métier.
Déclarer un risque sans démontrer son impact.

Bonne démarche

Combiner statique + dynamique.
Relier les artefacts entre eux.
Valider côté serveur les contrôles critiques.
Reproduire proprement les scénarios.
Documenter chaque finding avec une preuve claire.

Arbre de Décision — Mobile Pentest

Decision Flow

APK / IPA

Quel OS ? Quel framework ?

→

Statique

Config, secrets, permissions, composants

→

Dynamique

Logs, stockage, réseau, runtime

→

Backend

Auth, autorisation, logique métier

Si une protection bloque l'analyse

Identifier d'abord le mécanisme → déterminer ce qu'il protège → utiliser l'instrumentation appropriée dans le laboratoire → reprendre le test → documenter le contrôle et son efficacité.

Workflow Opérationnel — Du Binaire au Rapport

Workflow

Phase 1

Recon
APK/IPA, version, framework, environnement.

Phase 2

Statique
Manifest, code, secrets, dépendances, composants.

Phase 3

Dynamique
Runtime, réseau, stockage, instrumentation.

Phase 4

Validation
Reproduire et mesurer l'impact.

Phase 5

Remédiation
Identifier la cause racine.

Phase 6

Rapport
Preuve, impact, recommandation et classification.

Synthèse & Methodology Checklist — Chapitre 14

Récapitulatif

Checklist Pratique — Mobile Application Pentesting

1. Toujours partir du référentiel MASVS/MASTG pour structurer les tests et le rapport final, sur Android comme sur iOS.
2. Stockage local (MASVS-STORAGE) reste la catégorie qui produit le plus de constats — à vérifier en priorité.
3. Décompiler avant d'exploiter : jadx/apktool révèlent souvent des secrets codés en dur en quelques minutes.
4. Le pinning se contourne avant l'analyse réseau — sans ça, aucune interception via Burp Suite n'est possible.
5. MobSF automatise la baseline, mais l'analyse dynamique manuelle (Frida/Objection) reste indispensable pour les cas métier spécifiques.
6. La résilience (MASVS-RESILIENCE) se teste dans les deux sens : vérifier qu'elle existe, puis tenter de la contourner.