De nos jours, il y a une « app » pour tout. Et c’est bien là le problème. Ces apps se multiplient sur les terminaux nomades des collaborateurs. Il en résulte une augmentation de la surface d’attaque. Voici les 9 principales menaces pour la sécurité des applications mobiles que la plupart des entreprises continuent de bien trop négliger…
La volonté d’améliorer les fonctionnalités et les caractéristiques d’une application, ainsi que le déploiement rapide des mises à jour, se fait souvent au détriment de la sécurité qui tend à être une préoccupation secondaire.
En outre, avec les progrès technologiques, il est devenu non seulement plus facile de créer et de déployer des applications, mais aussi de pirater une application mobile.
Voici les 9 principales menaces pour la sécurité des applications mobiles.
Mauvaise protection de l’API
Dans le cadre de la création d’une application, il est presque certain qu’il va être nécessaire d’utiliser au moins une API pour obtenir des données d’une autre application. Par exemple, c’est ce qui permet à un site de réservation de voyages de récupérer des informations provenant d’hôtels et de compagnies aériennes et de les rassembler de manière ordonnée. C’est aussi ce qui permet à Google Maps d’afficher des itinéraires pour se rendre à un endroit donné. La plupart des applications modernes s’appuient sur des API pour une grande partie de leurs fonctionnalités. Malheureusement, de nombreux développeurs oublient de protéger leurs API car ils supposent que les acteurs malveillants ne les trouveront pas intéressantes. Cependant les API offrent l’accès à des informations stables et structurées, ce qui est exactement ce que recherchent les cybercriminels. Ils procéderont à de la rétro-ingénierie de l’application pour déterminer les APIs utilisées par l’application ciblée et ensuite ils exécuteront l’application avec un émulateur ou utiliseront une flotte de mobiles pour trouver des points d’accès.
Faiblesse des contrôles côté serveur
Les applications mobiles comportent une partie client et une partie serveur. La première est l’interface utilisateur, avec toutes les fonctionnalités. Mais pour que tout fonctionne, elle s’appuie sur la partie serveur, qui assure le bon fonctionnement de l’application. Ces deux parties communiquent généralement par l’intermédiaire d’une API. Les vulnérabilités côté serveur sont courantes et peuvent être exploitées via des APIs non sécurisées. Il peut s’agir de failles dans la logique du code, de règles d’authentification faibles, d’une mauvaise gestion des sessions, de configurations de serveur non sécurisées, de vulnérabilités dans le contrôle d’accès, et bien d’autres choses encore. Elles sont trop nombreuses pour être énumérées, mais elles se répartissent généralement en deux catégories : les vulnérabilités de code et les vulnérabilités de configuration.
Injections côté client
Un attaquant peut tenter de s’introduire dans une application en lui envoyant des données inhabituelles qui conduisent à un accès non autorisé. Ces données sont généralement manipulées de manière que l’application les interprète comme du code exécutable. Par exemple, une base de données SQL mobile peut être ciblée par un attaquant qui insère une requête créative dans laquelle il reçoit des données privées d’autres utilisateurs. Les injections SQL ne sont qu’une forme d’injection côté client. Une autre forme est l’inclusion de fichier local, où le pirate télécharge un fichier exécutable que l’application lit et exécute, ce qui peut entraîner une panne ou l’exposition de données sensibles.
Stockage non sécurisé de données sensibles
Les applications mobiles, même les applications bancaires, stockent souvent des données sensibles localement. Cela signifie que les codes PIN, les numéros de carte de crédit, les mots de passe, les données de connexion, etc. sont simplement stockés dans la mémoire d’un smartphone. Pire encore, ces données sont souvent stockées de manière non sécurisée. Si quelqu’un de compétent accède à un appareil (à distance ou non), il peut trouver et récupérer toutes ces données. Les données locales sensibles sont souvent stockées de manière non sécurisée en raison d’un chiffrement inadéquat. Certaines applications mobiles ne chiffrent pas du tout les données locales, ce qui est la pire des infractions. D’autres applications mobiles chiffrent les données locales mais ne stockent pas les clés de chiffrement correctement, ou utilisent des protocoles de chiffrement personnalisés qui ne sont pas considérés comme assez sûrs.
Mots de passe ou clés codés en dur
Il s’agit de l’erreur la plus élémentaire, mais elle se produit encore. Les développeurs codent souvent en dur les mots de passe, les clés d’API ou les clés OAuth pour faciliter la mise en œuvre, le support ou le débogage d’une application. Cela signifie que ces mots de passe ou clés sont écrits explicitement quelque part dans le code. Lorsque ces valeurs codées en dur sont ensuite découvertes parce qu’un cybercriminel a procédé à une rétro-ingénierie d’une application, l’entreprise s’expose à toutes sortes de risques.
Mauvaise sécurisation du code source
Le code source d’une application est ce qui lui permet de fonctionner. Il s’agit des éléments constitutifs. En outre, le code source coexiste souvent avec des clés d’API ou de chiffrement, des jetons d’authentification, des mots de passe d’utilisateurs et d’autres données sensibles qui ne doivent pas tomber entre de mauvaises mains. Lorsque nous parlons de code source, cela peut inclure du code provenant de tiers, tels que des partenaires ou des fournisseurs, ou même du simple code source ouvert. Si l’un de ces codes n’est pas sécurisé, l’application est en danger.
Fuite de données sensibles
La fuite de données consiste à exposer des données sensibles en ligne, accidentellement ou volontairement. C’est ce qui est arrivé à l’application mobile de stationnement Parkmobile lorsqu’une vulnérabilité dans un logiciel tiers a conduit à une fuite de données qui a exposé les courriels, dates de naissance, numéros de plaque d’immatriculation et numéros de téléphone de 21 millions d’utilisateurs. Parfois, ces fuites se produisent par inadvertance. Par exemple, Firebase est l’une des solutions de stockage de données les plus populaires pour les applications Android, mais elle est souvent mal configurée. Toute personne connaissant l’URL exacte d’une application construite avec Firebase peut facilement accéder aux bases de données de cette application, ce qui entraîne la fuite de données sensibles d’utilisateurs.
Transmission de données non sécurisées
Nous avons dit précédemment que les données non chiffrées ou mal chiffrées au repos ne sont pas sûres, il n’est donc pas surprenant que les données non chiffrées ou mal chiffrées en transit ne soient pas sûres non plus. Il n’est pas très compliqué pour un pirate informatique d’intercepter des données lorsqu’elles transitent à travers le Wi-Fi (en particulier les wifi publics non sécurisés) ou par le réseau de l’opérateur d’un appareil mobile. Si les données en transit sont souvent cryptées, elles sont aussi souvent mal configurées, ou les clés sont mal gérées, ou les développeurs utilisent un algorithme de cryptage client qui n’est pas aussi sûr que les algorithmes modernes. Il s’agit essentiellement des mêmes problèmes que pour les données non chiffrées ou mal chiffrées au repos, mais les pirates y accèdent par des canaux différents.
Logging et monitoring inadéquats
Une fois qu’une application est en ligne, il est important de savoir comment elle se comporte. L’entreprise veut comprendre quand les problèmes apparaissent, afin de pouvoir réagir à temps sans trop perturber l’expérience de l’utilisateur. Mais si des systèmes de journalisation et de surveillance appropriés ne sont pas mis en place, cela ne sera pas possible et créera des lacunes en matière d’information qui ne permettent pas de se défendre efficacement contre les incidents de sécurité.
____________________________
Par Antoine Vastel, Head of Research, DataDome
puis