Les applications mobiles font partie des éléments à sécuriser dans la mesure où elles manipulent des données personnelles, accèdent à des informations sensibles, et permettent dans certains cas de piloter des appareils à distance. Très utilisées dans le domaine de l’IoT, elles sont également au cœur du business model de nombreuses FinTech, HealthTech et entreprises innovantes de divers secteurs.
La sécurité des applications mobiles comprend différents aspects : la sécurité des applications mobiles elles-mêmes (version iOS ou Android), la sécurité des APIs et la sécurité des serveurs. La sécurité du back end (APIs et serveurs) est généralement plus critique que la sécurité du front end (apps iOS / Android), mais ceci dépend du contexte technique et fonctionnel de l’application elle-même.
Les applications mobiles, cibles privilégiées des cyberattaques
De manière générale, plus les flux de données transitent par les applications mobiles, plus les possibilités d’attaques et de compromissions augmentent. Les attaquants tirent parti de différents types de vulnérabilités : manque de contrôle côté serveur, problèmes de sécurisation du stockage des données, mauvaise sécurisation de l’échange de données, utilisation de composants tiers vulnérables, etc.
Pour renforcer la sécurité de vos applications mobiles, il est nécessaire de rechercher et corriger les vulnérabilités à la fois côté serveur et côté applicatif (à minima les APIs, mais dans certains cas aussi les apps mobiles elles-mêmes). Dans cet article, nous présenterons les vulnérabilités les plus souvent exploitées lors d’attaques sur les applications mobiles. Nous détaillerons également les bonnes pratiques et mesures à implémenter pour corriger ces vulnérabilités et réduire les risques.
Quelles sont les vulnérabilités courantes des applications mobiles et comment se protéger ?
Vulnérabilités serveur, failles d’injection et attaques IDOR
La plupart des communications entre une application et un utilisateur se fait via un serveur, car c’est ce dernier qui stocke et traite généralement toutes les données permettant à l’application de fonctionner : données d’authentification, données métier, données financières ou transactionnelles, données personnelles, etc. Par ailleurs, le composant côté serveur qui permet la communication et l’échange de données est généralement une API.
Étant un élément central dans le fonctionnement d’une application, le serveur est la cible privilégiée d’attaques, qui réussissent souvent en raison de vulnérabilités au niveau de la configuration de ce dernier ou des contrôles effectués par celui-ci. En cas de mauvaise configuration ou si des contrôles ne sont pas effectués, de nombreuses failles peuvent être exploitées et conduire à la compromission des données qui transitent, voire à la prise en main du serveur par des personnes malveillantes.
Les failles d’injection sont les plus répandues, les plus dangereuses et les plus diverses (injection SQL, de code, XSS, XPath, etc). Il s’agit pour un attaquant d’envoyer des requêtes ou des commandes de back-end permettant d’exécuter un code malveillant si des contrôles ne sont pas mis en place côté serveur. Par exemple, lors d’une attaque d’injection SQL, en manipulant une requête SQL, un attaquant peut récupérer des enregistrements de base de données ou manipuler le contenu de la base de données.
Des vulnérabilités côté serveur peuvent donc avoir des conséquences sévères. Il est nécessaire de mettre en place un système de validation des entrées pour écarter tout risque de compromission des données. Par ailleurs, pour contrer les possibilités d’injections SQL (qui sont des failles généralement critiques), il est recommandé d’utiliser des requêtes préparées (prepared statements) permettant de contrôler les informations envoyées par un utilisateur. En effet, s’il y a un seul aspect sécurité à retenir en réponse à cette problématique, c’est de ne jamais considérer toutes les données envoyées par un utilisateur ou tout système comme étant sûres.
Par ailleurs, c’est sur ce même type de vulnérabilité que reposent les attaques IDOR (Insecure Direct Object Reference). En s’appuyant sur le manque de contrôle de droits côté serveur, il devient possible pour un utilisateur de modifier le comportement d’une application, héberger des malwares, voler, altérer ou supprimer des données sensibles.
Pour se protéger contre ce type d’attaque, il est très fortement conseillé d’intégrer une couche sécurité en amont de la publication de vos applications mobiles sur les stores. Suivre les pratiques de développements sécurisés prend plus de temps mais permet de réduire considérablement les risques. Une fois que l’application est prête à être mise en ligne, voire après sa mise en ligne si cela n’a pas été anticipé au départ, réaliser un pentest en boite noire et/ou en boite grise permet d’identifier puis de corriger toutes les vulnérabilités qui pourraient être exploitées lors d’attaques informatiques.
Pour aller encore plus loin, un audit en boite blanche (analyse de code source et revue de configuration serveur orientées sécurité) permettra de rechercher directement des faiblesses en ayant accès au même niveau d’information que votre équipe interne.
Stockage non sécurisé des données
Une application mobile peut stocker différents types de données (cookies, fichiers textes, paramètres, etc.) via divers moyens de stockage : base de données SQL, magasins de données, fichiers XML, fichiers PLIST, carte SD, etc. Chiffrer les données sensibles utilisées dans l’application de manière efficace est une condition nécessaire pour en garantir la confidentialité.
Lorsqu’elles sont bien conçues, les applications exécutées sous iOS ou Android stockent les données qui n’ont pas vocation à être partagées dans un répertoire sécurisé. Toutes les données de l’application, y compris les préférences et les fichiers, sont stockées dans un répertoire unique par application. En général, seule votre application a un accès direct à ce répertoire et aucune autre application ne peut y accéder. Néanmoins, les deux systèmes d’exploitation ont des moyens de permettre de partager des données d’une application.
Par exemple, les applications peuvent demander des autorisations pour accéder à la bibliothèque photo, au dossier de téléchargements ou à la localisation de l’utilisateur. Il convient toutefois d’être prudent avec ces fonctionnalités car une application malveillante présente sur le device et disposant des mêmes autorisations pourrait lire les données d’autres applications. Pour réduire le risque, une bonne pratique consiste à demander uniquement les autorisations dont vous avez réellement besoin.
Par ailleurs, les devices rootés (Android) ou jailbreakés (iOS) permettent a de potentielles applications malveillantes d’accéder aux données des autres applications, ce qui augmente le risque de compromission. En cas de perte ou de vol d’un device, un attaquant pourra plus facilement récupérer ces données.
Ainsi, pour un stockage sécurisé, il est essentiel que les données soient protégées et chiffrées efficacement. Pour les applications mobiles, cela signifie chiffrer toutes les informations et données sensibles stockées par l’application et appliquer les autorisations appropriées. iOS et Android offrent tous deux des magasins de stockage sécurisé appelé Keychain (pour iOS) et Keystore (sous Android) qui permettent de chiffrer des données.
Sécurité des échanges de données et Attaques Man in the Middle
Les fonctionnalités de la plupart des applications reposent sur la communication avec un serveur. Suivant les besoins métiers, une application envoie ou reçoit différents types de données : identifiants de connexion, données de session utilisateur, données personnelles, données bancaires, etc. HTTP est la norme en matière de communication client-serveur. Cependant, les communications peuvent potentiellement être interceptées, modifiées ou redirigées car ce protocole n’intègre aucun dispositif de sécurité.
En effet, une des attaques courantes utilise l’empoisonnement de cache ARP (ARP poisoning). Cette technique permet à un attaquant de détourner des flux de communications transitant entre une application et une passerelle : routeur, box, etc. En somme, c’est une attaque Man In The Middle dans laquelle un attaquant envoie de faux messages pour empoisonner le cache ARP d’un utilisateur et ainsi lier son adresse MAC à l’adresse IP légitime. Ce faisant, il peut ensuite intercepter, modifier ou supprimer toute communication qui transite entre l’application et le serveur.
Se prémunir contre les attaques Man the Middle est assez simple. Il suffit d’utiliser le protocole de sécurité TLS (successeur de SSL) pour rajouter une couche de sécurité qui garantit la confidentialité et l’intégrité des données qui transitent grâce au chiffrement des données. Les connexions HTTP sécurisées par TLS sont appelées connexions HTTP Secure (HTTPS).
Néanmoins, TLS et son prédécesseur SSL ne sont pas exempts de failles de sécurité. Depuis leur introduction, de multiples vulnérabilités dans différentes couches des protocoles ou des implémentations des protocoles ont été trouvées et exploitées. Pour résoudre les problèmes de sécurité, de nouvelles versions du protocole sont publiées régulièrement. L’utilisation d’une version plus récente permet de se protéger des failles de sécurité connues des anciennes versions. Il est donc crucial de réagir rapidement en installant les nouvelles versions pour contrer les attaques potentielles.
Par ailleurs, TLS s’appuie sur des certificats numériques pour authentifier un serveur auprès d’une application. Ces certificats doivent être émis (et signés) par des autorités de certification et ils possèdent de multiples caractéristiques qui doivent être vérifiées pour qu’un certificat soit valide pour un domaine donné. Cependant, il existe un risque car des attaquants peuvent émettre des certificats douteux, en apparence sécurisés, ce qui leur permet d’intercepter des communications d’utilisateurs.
Pour rajouter une couche de sécurité supplémentaire, il est conseillé d’utiliser le « certificate pinning », qui est une méthode complémentaire de validation du certificat du serveur. En plus d’effectuer les contrôles classiques sur le certificat présenté par le serveur, comme valider la chaîne de certification jusqu’à un certificat racine ou sa date de validité, l’application contrôle également certaines caractéristiques du certificat, comme son numéro de série et la clef publique qui lui est associée. Cette méthode présente l’avantage d’être plus robuste que la méthode classique, et permet de ne plus dépendre que du système ou des autorités de certification racine pour s’assurer que le certificat présenté est le bon.
Sécurité des composants tiers
La plupart des applications mobiles utilise des composants tiers : librairies, frameworks, API tierces, etc. L’utilisation de ces composants permet de réduire considérablement le temps nécessaire entre la conception d’une application et sa mise sur le marché. Ils peuvent cependant représenter un risque de sécurité important, avec des possibilités de vulnérabilités diverses : injections, XSS, mauvaise configuration, etc.
Nous avons décrit les problématiques de sécurité liées à l’utilisation des composants tiers dans notre article précédent sur les vulnérabilités et attaques courantes des applications web. La même logique s’applique dans le contexte des applications mobiles. Vous pouvez vous référer à cet article pour la sécurité des composants tiers, ainsi que pour d’autres aspects tels que la sécurité de l’authentification, les failles logiques… qui concernent également les applications mobiles.
Réaliser un test d’intrusion d’application mobile pour évaluer et renforcer votre sécurité
Un bon moyen de renforcer concrètement la sécurité de vos applications mobiles est de réaliser un test d’intrusion. Il s’agit de mettre à l’épreuve votre application en testant méthodiquement un périmètre pour identifier les failles de sécurité et proposer les correctifs appropriés.
Un test d’intrusion d’application mobile permet de déceler des vulnérabilités sur la couche serveurs ainsi que sur la couche applicative (failles des applications web pour les APIs et failles des applications mobiles pour les apps iOS et Android). Les tests combinent une analyse statique et une analyse dynamique de l’application mobile.
Exemples de failles côté serveur :
- Services ouverts et mal sécurisés
- Logiciels non à jour
- Éléments de sécurité contournables
- Erreurs de configuration
Exemples de failles sur les applications web (OWASP Top 10 Web) :
- Failles d’injections
- Vulnérabilités dans la gestion de l’authentification et des sessions
- Exposition de données sensibles
- Vulnérabilités d’injection XML (XXE)
- Manque de contrôle sur les accès
- Problèmes de configuration (serveur, framework, librairies)
- Cross-Site Scripting (XSS)
- Vulnérabilités de sérialisation
- Utilisation de composants tiers vulnérables
- Manque de logging et de monitoring
Exemples de failles sur les applications mobiles (OWASP Top 10 Mobile) :
- Mauvaise utilisation de la plateforme de développement
- Vulnérabilités sur le stockage des données dans l’application
- Communications non sécurisées
- Mécanismes d’authentification
- Cryptographie
- Gestion des autorisations
- Problématiques de qualité de code
- Modification du code à la volée / repackaging
- Reverse engineering
- Fonctionnalités cachées
Par ailleurs, contrairement à un scanner de vulnérabilités, un test d’intrusion ne se limite pas à la découverte de failles mais intègre une phase d’exploitation, réalisée manuellement par les pentesters. Elle permet, tout comme une personne malveillante le ferait, d’utiliser les failles découvertes comme « pivot » pour découvrir potentiellement d’autres vulnérabilités, et ainsi d’éprouver plus efficacement la sécurité de vos applications mobiles.
Le test d’intrusion sera plus ou moins approfondi, et les pentesters seront plus ou moins exhaustifs dans la recherche de failles, selon le périmètre et les conditions définies pour la prestation. Il est conseillé de réaliser à minima des tests en boite noire, c’est à dire rechercher des vulnérabilités sur le périmètre accessible à un attaquant externe. Pour tester une API mobile, il est généralement conseillé de réaliser des tests en boite grise afin de permettre aux pentesters de manipuler correctement l’API et de gagner du temps pour identifier les failles de sécurité les plus importantes. Pour des tests visant à assurer un niveau maximum de sécurité, des tests en boite blanche permettent de pousser au plus loin les recherches, ce qui suppose de fournir aux pentesters un accès au code source de l’application mobile et à l’infrastructure serveur.
Quelle que soit l’approche choisie, le résultat d’un test d’intrusion est un rapport technique détaillant les vulnérabilités identifiées ainsi que les correctifs à implémenter.
Vaadata accompagne des entreprises de toute taille et de tous secteurs d’activité avec des tests d’intrusion d’applications mobiles. Nos offres s’adaptent aux enjeux sécurité, au niveau d’exposition aux risques et au budget des startups comme des grandes entreprises. Pour un pentest d’application mobile, il faut généralement prévoir un budget compris entre 1 500€ et 10 000€, selon la complexité fonctionnelle et technique de l’application, ainsi que le niveau de profondeur souhaité pour les tests.
N’hésitez pas à nous contacter pour toute question relative à un projet de tests d’intrusion sur votre application mobile.
