En bref
Un test d’intrusion d’application mobile vérifie ce qu’un attaquant obtient de votre application installée sur son propre téléphone : données stockées en clair, trafic interceptable, authentification contournable, logique côté client modifiable et, surtout, API appelées par l’application. Il suit en général le référentiel OWASP MASVS et le guide de test MASTG, sur iOS comme sur Android. Il dure de quelques jours à deux semaines selon le périmètre et se prépare avec des builds de test, des comptes de chaque rôle et la documentation des API.
Pourquoi une application mobile se teste-t-elle autrement qu’une application web ?
Une application web s’exécute pour l’essentiel sur vos serveurs : l’attaquant n’en voit que ce que vous lui envoyez. Une application mobile est livrée entière à chaque utilisateur. Son paquet peut être téléchargé, décompilé et analysé hors ligne, et l’appareil sur lequel elle tourne est celui de l’attaquant, qui peut le modifier, intercepter son trafic et instrumenter l’application pendant son exécution.
Conséquence directe : tout ce que le binaire contient doit être considéré comme public. Une clé d’API, une adresse de serveur interne, une règle de validation ou un contrôle de licence codés dans l’application sont lisibles. Et tout contrôle effectué seulement côté client, par exemple masquer un bouton ou vérifier un droit avant d’envoyer une requête, peut être supprimé par l’attaquant, qui appelle alors le serveur directement.
Que couvre le référentiel MASVS ?
Le MASVS : définition (Mobile Application Security Verification Standard) est le référentiel de l’OWASP pour la sécurité des applications mobiles. Le projet Mobile Application Security publie aussi le guide de test MASTG, qui décrit comment vérifier chaque exigence sur iOS et Android, une énumération de faiblesses nommée MASWE et des profils qui aident à choisir le niveau de contrôle selon le risque. Le MASVS regroupe ses exigences en huit familles.
- STORAGE : où sont stockées les données sensibles sur l’appareil, et ce qu’en lisent les sauvegardes, les journaux et les autres applications.
- CRYPTO : algorithmes, clés et leur protection, y compris l’usage du magasin de clés de la plateforme.
- AUTH : authentification et autorisation, sessions et biométrie liée à une preuve côté serveur.
- NETWORK : chiffrement du trafic, validation des certificats, épinglage.
- PLATFORM : interactions avec le système et les autres applications (liens profonds, composants exportés, WebView, presse-papiers).
- CODE : qualité du code, gestion des dépendances, traitement des entrées, mises à jour.
- RESILIENCE : résistance à la rétro-ingénierie et à l’altération, à doser selon le risque.
- PRIVACY : minimisation des données collectées, transparence et contrôle laissés à l’utilisateur.
Quels défauts un test d’intrusion mobile cherche-t-il en priorité ?
- Secrets embarqués : clés d’API, jetons, identifiants d’environnements de test dans le paquet, que n’importe qui peut extraire.
- Données sensibles stockées sans protection : jetons de session, informations personnelles dans des bases locales, des fichiers de préférences ou des sauvegardes.
- Trafic réseau interceptable : certificats mal validés, absence d’épinglage là où il est attendu, protocoles non chiffrés sur certains appels.
- Authentification contournable : biométrie qui ne dépend que d’un indicateur local, sessions qui ne se révoquent pas, jetons de longue durée.
- Composants exposés : liens profonds qui déclenchent des actions sans confirmation, activités exportées, WebView qui charge du contenu non fiable.
- Défauts d’API : accès aux objets d’autres utilisateurs, champs masqués dans l’interface mais renvoyés par le serveur, absence de limite sur les tentatives.
Que faut-il préparer avant de commander un test ?
Plus la préparation est complète, plus le temps de la mission sert à chercher des défauts plutôt qu’à comprendre l’application. Prévoyez les éléments suivants avant le début.
- Un build installable de test (APK pour Android, version de test pour iOS), si possible avec les protections anti-analyse désactivées sur une version de travail.
- Des comptes de test pour chaque rôle, dans au moins deux organisations si l’application est multi-clients.
- La documentation des API (OpenAPI par exemple) et un environnement de préproduction avec des données fictives.
- La liste des fonctionnalités sensibles : paiement, changement de mot de passe, partage de données, accès administrateur.
- Le niveau de résistance à la rétro-ingénierie attendu, ou au moins ce que l’application protège et ce que coûterait une copie.
Que ne dit pas un test d’intrusion mobile ?
Un test porte sur une version précise, dans des conditions décrites dans le rapport. Il ne prouve pas l’absence de vulnérabilités, et la version suivante peut en introduire de nouvelles. Il ne remplace pas non plus la sécurité du reste du système d’information, ni la revue du code quand il est disponible. Enfin, la résistance à la rétro-ingénierie retarde un attaquant motivé, mais ne l’arrête pas : elle ne doit jamais tenir lieu de contrôle côté serveur. Un bon rapport indique ces limites au lieu de les cacher.
À retenir
- 1Tout ce que contient une application mobile doit être considéré comme lisible, et tout contrôle uniquement côté client comme contournable.
- 2Le MASVS structure le test en huit familles ; le MASTG décrit comment vérifier chacune sur iOS et Android.
- 3Les API appelées par l’application doivent être dans le périmètre, car c’est là que se trouvent les défauts les plus coûteux.
- 4Fournissez un build de test, des comptes par rôle, la documentation des API et le niveau de résistance attendu avant la mission.
Sources citées
- OWASP MASVS : Mobile Application Security Verification Standard, OWASP Foundation
- OWASP MASTG : Mobile Application Security Testing Guide, OWASP Foundation
- OWASP Mobile Top 10, OWASP Foundation
- NIST SP 800-115 : Technical Guide to Information Security Testing and Assessment, NIST
Comment se déroule un test, étape par étape ?