Aller au contenu
Narvy

OWASP MASVS en pratique : contrôles, profils et tests

Les 24 contrôles du MASVS v2.1, le rôle de MASVS, MASWE et MASTG, le choix d'un profil MAS et l'application du standard sur un vrai projet mobile.

Narvy7 min de lecture

L'OWASP MASVS (Mobile Application Security Verification Standard) est le standard de l'OWASP pour la sécurité des applications mobiles. La dernière version publiée sur la page GitHub du projet est la v2.1.0, du 18 janvier 2024. Elle ajoute le groupe MASVS-PRIVACY à la structure de la v2.0.0, sortie en avril 2023.

Cet article explique comment le standard est organisé et comment l'appliquer sur un vrai projet : choisir un profil, transformer les contrôles en travail, tester, rendre compte.

Trois documents, trois rôles

Le projet OWASP MAS publie trois documents complémentaires.

Document Répond à Exemple
MASVS Que doit garantir l'application ? MASVS-STORAGE-1
MASWE Quelle faiblesse met ce contrôle en défaut ? MASWE-0004, donnée sensible codée en dur dans le paquet
MASTG Comment la tester sur Android ou iOS ? MASTG-TEST-0212, clés codées en dur dans le code

La page d'évaluation du MASVS décrit ce partage : les contrôles restent généraux et abstraits, le MASTG apporte les recommandations et les procédures de test propres à chaque système. Toutes les faiblesses n'ont pas encore de test. MASWE-0004 indique par exemple que le MASTG n'en contient aucun pour l'instant, et la page du profil MAS-L1 explique comment évaluer une faiblesse dans ce cas : partir de ses « Modes of Introduction » et s'appuyer sur des tests voisins.

Les 24 contrôles

Le MASVS v2.1 compte 8 groupes et 24 contrôles. L'énoncé officiel est en anglais ; la traduction ci-dessous est la nôtre.

Contrôle Énoncé
MASVS-STORAGE-1 L'application stocke les données sensibles de façon sûre.
MASVS-STORAGE-2 L'application empêche les fuites de données sensibles.
MASVS-CRYPTO-1 L'application emploie une cryptographie forte et actuelle, selon les bonnes pratiques du secteur.
MASVS-CRYPTO-2 L'application gère ses clés selon les bonnes pratiques du secteur.
MASVS-AUTH-1 L'application utilise des protocoles d'authentification et d'autorisation sûrs et suit les bonnes pratiques associées.
MASVS-AUTH-2 L'application réalise l'authentification locale de façon sûre, selon les bonnes pratiques de la plateforme.
MASVS-AUTH-3 L'application protège les opérations sensibles par une authentification supplémentaire.
MASVS-NETWORK-1 L'application sécurise tout son trafic réseau selon les bonnes pratiques actuelles.
MASVS-NETWORK-2 L'application épingle l'identité de tous les serveurs que le développeur contrôle.
MASVS-PLATFORM-1 L'application utilise les mécanismes d'IPC de façon sûre.
MASVS-PLATFORM-2 L'application utilise les WebViews de façon sûre.
MASVS-PLATFORM-3 L'application utilise l'interface utilisateur de façon sûre.
MASVS-CODE-1 L'application exige une version récente de la plateforme.
MASVS-CODE-2 L'application dispose d'un mécanisme pour imposer les mises à jour.
MASVS-CODE-3 L'application n'utilise que des composants sans vulnérabilité connue.
MASVS-CODE-4 L'application valide et assainit toutes les entrées non fiables.
MASVS-RESILIENCE-1 L'application vérifie l'intégrité de la plateforme.
MASVS-RESILIENCE-2 L'application met en œuvre des protections contre la modification.
MASVS-RESILIENCE-3 L'application met en œuvre des protections contre l'analyse statique.
MASVS-RESILIENCE-4 L'application met en œuvre des protections contre l'analyse dynamique.
MASVS-PRIVACY-1 L'application limite l'accès aux données et ressources sensibles.
MASVS-PRIVACY-2 L'application empêche l'identification de l'utilisateur.
MASVS-PRIVACY-3 L'application est transparente sur la collecte et l'usage des données.
MASVS-PRIVACY-4 L'application donne à l'utilisateur le contrôle de ses données.

Les niveaux sont devenus des profils

Le MASVS v1 associait des niveaux (L1, L2, R) à chaque exigence. Les notes de version de la v2.0.0 expliquent pourquoi les contrôles v2 n'en ont plus : les niveaux sont passés dans les tests du MASTG, pour qu'un même contrôle puisse être testé différemment selon l'application. L'exemple donné porte sur MASVS-STORAGE-1 : stocker des données non chiffrées dans le stockage interne de l'application est acceptable en L1, alors que L2 exige le chiffrement.

La page des MAS Testing Profiles définit quatre profils par défaut selon le modèle d'attaquant :

Profil Modèle d'attaquant (résumé)
MAS-L1 Les autres applications installées sur l'appareil sont des adversaires.
MAS-L2 Le système d'exploitation n'est pas digne de confiance et l'attaquant peut avoir un accès physique à l'appareil.
MAS-R L'utilisateur de l'appareil est l'attaquant, rétro-ingénieurs et tricheurs compris.
MAS-P Pas centré sur un attaquant : protection des données personnelles des utilisateurs.

La même page recommande un modèle de menace pour choisir les contrôles, et présente ces profils comme la solution de repli quand un profil sur mesure n'est pas envisageable. Ses exemples placent une application d'actualités ou un agenda en L1+P, et les applications qui manipulent localisation, paiement, données de santé, jetons d'accès ou clés d'API (une messagerie, une application de santé) en L2+P. Les exemples ajoutent R quand l'application porte en plus des actifs métier, comme de la propriété intellectuelle ou des revenus publicitaires.

Appliquer le MASVS sur un projet

  1. Choisir le profil. Notez ce que l'application stocke, ce qu'elle peut faire au nom de l'utilisateur et qui aurait intérêt à l'attaquer. La réponse désigne L1 ou L2, et indique si R et P s'appliquent.
  2. Transformer les contrôles en exigences. La page des profils prévoit un usage « secure by design » : intégrer les contrôles retenus dès la conception et le développement. Un contrôle comme MASVS-NETWORK-1 devient des tickets concrets : TLS partout, aucune exception en clair, validation des certificats laissée active.
  3. Associer chaque exigence à des tests. Utilisez les pages de test du MASTG pour Android et iOS. Automatisez dans la CI ce qui peut l'être.
  4. Garder une revue manuelle au planning. La page d'évaluation est explicite : il n'est pas possible de terminer une vérification MASVS avec des outils automatiques seuls. La logique métier, les parcours d'authentification et les mentions de confidentialité demandent une personne.
  5. Rendre compte par identifiant de contrôle. Pour un rapport de certification, la même page demande le périmètre de la vérification, un résumé des tests réussis et échoués, et la façon de corriger les échecs.

Erreurs fréquentes

Mélanger les identifiants v1 et v2. Les exigences v1 étaient numérotées comme MSTG-STORAGE-1, les contrôles v2 s'appellent comme MASVS-STORAGE-1. Les numéros ne se correspondent pas. MASWE-0004, par exemple, correspond à MSTG-STORAGE-1 et MSTG-CODE-2 en v1, et à MASVS-STORAGE-1 en v2. Vérifiez la correspondance sur la page MASWE avant de réutiliser une ancienne checklist.

Ne tester que l'application. Le MASVS ne couvre que le côté client. La page d'évaluation renvoie les serveurs vers l'OWASP ASVS et le Web Security Testing Guide.

Prendre « certifié MASVS » au pied de la lettre. L'OWASP ne certifie ni éditeur, ni vérificateur, ni logiciel. Une certification ou un label qui revendique la conformité MASVS n'est pas validé par l'OWASP.

Appliquer tous les contrôles à toutes les applications. Les contrôles RESILIENCE comptent quand l'utilisateur est l'attaquant. C'est le modèle de menace qui tranche, et tout écart par rapport au profil retenu doit être justifié et documenté, comme le demande la page Using the MASVS.

Sources officielles

  1. OWASP MASVSmas.owasp.org
  2. Versions publiées du MASVS (v2.0.0, v2.1.0)github.com
  3. OWASP MASVS : Using the MASVSmas.owasp.org
  4. OWASP MASVS : Assessment and Certificationmas.owasp.org
  5. OWASP MAS Testing Profilesmas.owasp.org
  6. OWASP MASWEmas.owasp.org
  7. OWASP MASTGmas.owasp.org