{"id":3774,"date":"2021-06-22T11:21:30","date_gmt":"2021-06-22T09:21:30","guid":{"rendered":"https:\/\/www.vaadata.com\/blog\/?p=3774"},"modified":"2021-07-06T17:13:33","modified_gmt":"2021-07-06T15:13:33","slug":"comment-renforcer-la-securite-de-vos-applications-mobiles-pour-contrer-les-attaques-les-plus-courantes","status":"publish","type":"post","link":"https:\/\/www.vaadata.com\/blog\/fr\/comment-renforcer-la-securite-de-vos-applications-mobiles-pour-contrer-les-attaques-les-plus-courantes\/","title":{"rendered":"Comment renforcer la s\u00e9curit\u00e9 de vos applications mobiles pour contrer les attaques les plus courantes ?"},"content":{"rendered":"\n

Les applications mobiles<\/strong> font partie des \u00e9l\u00e9ments \u00e0 s\u00e9curiser dans la mesure o\u00f9 elles manipulent des donn\u00e9es personnelles, acc\u00e8dent \u00e0 des informations sensibles, et permettent dans certains cas de piloter des appareils \u00e0 distance. Tr\u00e8s utilis\u00e9es dans le domaine de l\u2019IoT, elles sont \u00e9galement au c\u0153ur du business model de nombreuses FinTech, HealthTech et entreprises innovantes de divers secteurs.<\/p>\n\n\n\n

\"Comment<\/figure><\/div>\n\n\n\n

La s\u00e9curit\u00e9 des applications mobiles comprend diff\u00e9rents aspects : la s\u00e9curit\u00e9 des applications mobiles elles-m\u00eames (version iOS ou Android), la s\u00e9curit\u00e9 des APIs et la s\u00e9curit\u00e9 des serveurs. La s\u00e9curit\u00e9 du back end (APIs et serveurs) est g\u00e9n\u00e9ralement plus critique que la s\u00e9curit\u00e9 du front end (apps iOS \/ Android), mais ceci d\u00e9pend du contexte technique et fonctionnel de l\u2019application elle-m\u00eame.<\/p>\n\n\n\n\n\n\n\n

Les applications mobiles, cibles privil\u00e9gi\u00e9es des cyberattaques<\/h2>\n\n\n\n

De mani\u00e8re g\u00e9n\u00e9rale, plus les flux de donn\u00e9es transitent par les applications mobiles, plus les possibilit\u00e9s d\u2019attaques et de compromissions augmentent. Les attaquants tirent parti de diff\u00e9rents types de vuln\u00e9rabilit\u00e9s : manque de contr\u00f4le c\u00f4t\u00e9 serveur, probl\u00e8mes de s\u00e9curisation du stockage des donn\u00e9es, mauvaise s\u00e9curisation de l\u2019\u00e9change de donn\u00e9es, utilisation de composants tiers vuln\u00e9rables, etc.<\/p>\n\n\n\n

Pour renforcer la s\u00e9curit\u00e9 de vos applications mobiles<\/strong>, il est n\u00e9cessaire de rechercher et corriger les vuln\u00e9rabilit\u00e9s \u00e0 la fois c\u00f4t\u00e9 serveur et c\u00f4t\u00e9 applicatif (\u00e0 minima les APIs, mais dans certains cas aussi les apps mobiles elles-m\u00eames). Dans cet article, nous pr\u00e9senterons les vuln\u00e9rabilit\u00e9s les plus souvent exploit\u00e9es lors d\u2019attaques sur les applications mobiles. Nous d\u00e9taillerons \u00e9galement les bonnes pratiques et mesures \u00e0 impl\u00e9menter pour corriger ces vuln\u00e9rabilit\u00e9s et r\u00e9duire les risques.<\/p>\n\n\n\n

Quelles sont les vuln\u00e9rabilit\u00e9s courantes des applications mobiles et comment se prot\u00e9ger ?<\/h2>\n\n\n\n

Vuln\u00e9rabilit\u00e9s serveur, failles d\u2019injection et attaques IDOR<\/h3>\n\n\n\n

La plupart des communications entre une application et un utilisateur se fait via un serveur, car c\u2019est ce dernier qui stocke et traite g\u00e9n\u00e9ralement toutes les donn\u00e9es permettant \u00e0 l\u2019application de fonctionner : donn\u00e9es d\u2019authentification, donn\u00e9es m\u00e9tier, donn\u00e9es financi\u00e8res ou transactionnelles, donn\u00e9es personnelles, etc. Par ailleurs, le composant c\u00f4t\u00e9 serveur qui permet la communication et l\u2019\u00e9change de donn\u00e9es est g\u00e9n\u00e9ralement une API.<\/p>\n\n\n\n

\u00c9tant un \u00e9l\u00e9ment central dans le fonctionnement d\u2019une application, le serveur est la cible privil\u00e9gi\u00e9e d\u2019attaques, qui r\u00e9ussissent souvent en raison de vuln\u00e9rabilit\u00e9s au niveau de la configuration de ce dernier ou des contr\u00f4les effectu\u00e9s par celui-ci. En cas de mauvaise configuration ou si des contr\u00f4les ne sont pas effectu\u00e9s, de nombreuses failles peuvent \u00eatre exploit\u00e9es et conduire \u00e0 la compromission des donn\u00e9es qui transitent, voire \u00e0 la prise en main du serveur par des personnes malveillantes.<\/p>\n\n\n\n

Les failles d\u2019injection sont les plus r\u00e9pandues, les plus dangereuses et les plus diverses (injection SQL, de code, XSS, XPath, etc). Il s\u2019agit pour un attaquant d\u2019envoyer des requ\u00eates ou des commandes de back-end permettant d\u2019ex\u00e9cuter un code malveillant si des contr\u00f4les ne sont pas mis en place c\u00f4t\u00e9 serveur. Par exemple, lors d\u2019une attaque d\u2019injection SQL, en manipulant une requ\u00eate SQL, un attaquant peut r\u00e9cup\u00e9rer des enregistrements de base de donn\u00e9es ou manipuler le contenu de la base de donn\u00e9es.<\/p>\n\n\n\n

Des vuln\u00e9rabilit\u00e9s c\u00f4t\u00e9 serveur peuvent donc avoir des cons\u00e9quences s\u00e9v\u00e8res. Il est n\u00e9cessaire de mettre en place un syst\u00e8me de validation des entr\u00e9es pour \u00e9carter tout risque de compromission des donn\u00e9es. Par ailleurs, pour contrer les possibilit\u00e9s d\u2019injections SQL (qui sont des failles g\u00e9n\u00e9ralement critiques), il est recommand\u00e9 d\u2019utiliser des requ\u00eates pr\u00e9par\u00e9es (prepared statements) permettant de contr\u00f4ler les informations envoy\u00e9es par un utilisateur. En effet, s\u2019il y a un seul aspect s\u00e9curit\u00e9 \u00e0 retenir en r\u00e9ponse \u00e0 cette probl\u00e9matique, c\u2019est de ne jamais consid\u00e9rer toutes les donn\u00e9es envoy\u00e9es par un utilisateur ou tout syst\u00e8me comme \u00e9tant s\u00fbres.<\/p>\n\n\n\n

Par ailleurs, c\u2019est sur ce m\u00eame type de vuln\u00e9rabilit\u00e9 que reposent les attaques IDOR (Insecure Direct Object Reference). En s\u2019appuyant sur le manque de contr\u00f4le de droits c\u00f4t\u00e9 serveur, il devient possible pour un utilisateur de modifier le comportement d\u2019une application, h\u00e9berger des malwares, voler, alt\u00e9rer ou supprimer des donn\u00e9es sensibles.<\/p>\n\n\n\n

Pour se prot\u00e9ger contre ce type d\u2019attaque, il est tr\u00e8s fortement conseill\u00e9 d\u2019int\u00e9grer une couche s\u00e9curit\u00e9 en amont de la publication de vos applications mobiles sur les stores. Suivre les pratiques de d\u00e9veloppements s\u00e9curis\u00e9s prend plus de temps mais permet de r\u00e9duire consid\u00e9rablement les risques. Une fois que l\u2019application est pr\u00eate \u00e0 \u00eatre mise en ligne, voire apr\u00e8s sa mise en ligne si cela n\u2019a pas \u00e9t\u00e9 anticip\u00e9 au d\u00e9part, r\u00e9aliser un pentest en boite noire et\/ou en boite grise<\/a> permet d\u2019identifier puis de corriger toutes les vuln\u00e9rabilit\u00e9s qui pourraient \u00eatre exploit\u00e9es lors d\u2019attaques informatiques.<\/p>\n\n\n\n

Pour aller encore plus loin, un audit en boite blanche (analyse de code source et revue de configuration serveur orient\u00e9es s\u00e9curit\u00e9)<\/a> permettra de rechercher directement des faiblesses en ayant acc\u00e8s au m\u00eame niveau d\u2019information que votre \u00e9quipe interne.<\/p>\n\n\n\n

Stockage non s\u00e9curis\u00e9 des donn\u00e9es<\/h3>\n\n\n\n

Une application mobile peut stocker diff\u00e9rents types de donn\u00e9es (cookies, fichiers textes, param\u00e8tres, etc.) via divers moyens de stockage : base de donn\u00e9es SQL, magasins de donn\u00e9es, fichiers XML, fichiers PLIST, carte SD, etc. Chiffrer les donn\u00e9es sensibles utilis\u00e9es dans l\u2019application de mani\u00e8re efficace est une condition n\u00e9cessaire pour en garantir la confidentialit\u00e9.<\/p>\n\n\n\n

Lorsqu\u2019elles sont bien con\u00e7ues, les applications ex\u00e9cut\u00e9es sous iOS ou Android stockent les donn\u00e9es qui n\u2019ont pas vocation \u00e0 \u00eatre partag\u00e9es dans un r\u00e9pertoire s\u00e9curis\u00e9. Toutes les donn\u00e9es de l\u2019application, y compris les pr\u00e9f\u00e9rences et les fichiers, sont stock\u00e9es dans un r\u00e9pertoire unique par application. En g\u00e9n\u00e9ral, seule votre application a un acc\u00e8s direct \u00e0 ce r\u00e9pertoire et aucune autre application ne peut y acc\u00e9der. N\u00e9anmoins, les deux syst\u00e8mes d’exploitation ont des moyens de permettre de partager des donn\u00e9es d\u2019une application.<\/p>\n\n\n\n

Par exemple, les applications peuvent demander des autorisations pour acc\u00e9der \u00e0 la biblioth\u00e8que photo, au dossier de t\u00e9l\u00e9chargements ou \u00e0 la localisation de l’utilisateur. Il convient toutefois d’\u00eatre prudent avec ces fonctionnalit\u00e9s car une application malveillante pr\u00e9sente sur le device et disposant des m\u00eames autorisations pourrait lire les donn\u00e9es d\u2019autres applications. Pour r\u00e9duire le risque, une bonne pratique consiste \u00e0 demander uniquement les autorisations dont vous avez r\u00e9ellement besoin.<\/p>\n\n\n\n

Par ailleurs, les devices root\u00e9s (Android) ou jailbreak\u00e9s (iOS) permettent a de potentielles applications malveillantes d\u2019acc\u00e9der aux donn\u00e9es des autres applications, ce qui augmente le risque de compromission. En cas de perte ou de vol d\u2019un device, un attaquant pourra plus facilement r\u00e9cup\u00e9rer ces donn\u00e9es.<\/p>\n\n\n\n

Ainsi, pour un stockage s\u00e9curis\u00e9, il est essentiel que les donn\u00e9es soient prot\u00e9g\u00e9es et chiffr\u00e9es efficacement. Pour les applications mobiles, cela signifie chiffrer toutes les informations et donn\u00e9es sensibles stock\u00e9es par l’application et appliquer les autorisations appropri\u00e9es. iOS et Android offrent tous deux des magasins de stockage s\u00e9curis\u00e9 appel\u00e9 Keychain (pour iOS) et Keystore (sous Android) qui permettent de chiffrer des donn\u00e9es.  <\/p>\n\n\n\n

S\u00e9curit\u00e9 des \u00e9changes de donn\u00e9es et Attaques Man in the Middle<\/h3>\n\n\n\n

Les fonctionnalit\u00e9s de la plupart des applications reposent sur la communication avec un serveur. Suivant les besoins m\u00e9tiers, une application envoie ou re\u00e7oit diff\u00e9rents types de donn\u00e9es : identifiants de connexion, donn\u00e9es de session utilisateur, donn\u00e9es personnelles, donn\u00e9es bancaires, etc. HTTP est la norme en mati\u00e8re de communication client-serveur. Cependant, les communications peuvent potentiellement \u00eatre intercept\u00e9es, modifi\u00e9es ou redirig\u00e9es car ce protocole n\u2019int\u00e8gre aucun dispositif de s\u00e9curit\u00e9.<\/p>\n\n\n\n

En effet, une des attaques courantes utilise l\u2019empoisonnement de cache ARP (ARP poisoning). Cette technique permet \u00e0 un attaquant de d\u00e9tourner des flux de communications transitant entre une application et une passerelle : routeur, box, etc. En somme, c\u2019est une attaque Man In The Middle dans laquelle un attaquant envoie de faux messages pour empoisonner le cache ARP d\u2019un utilisateur et ainsi lier son adresse MAC \u00e0 l\u2019adresse IP l\u00e9gitime. Ce faisant, il peut ensuite intercepter, modifier ou supprimer toute communication qui transite entre l\u2019application et le serveur.<\/p>\n\n\n\n

Se pr\u00e9munir contre les attaques Man the Middle est assez simple. Il suffit d\u2019utiliser le protocole de s\u00e9curit\u00e9 TLS (successeur de SSL) pour rajouter une couche de s\u00e9curit\u00e9 qui garantit la confidentialit\u00e9 et l’int\u00e9grit\u00e9 des donn\u00e9es qui transitent gr\u00e2ce au chiffrement des donn\u00e9es. Les connexions HTTP s\u00e9curis\u00e9es par TLS sont appel\u00e9es connexions HTTP Secure (HTTPS).<\/p>\n\n\n\n

N\u00e9anmoins, TLS et son pr\u00e9d\u00e9cesseur SSL ne sont pas exempts de failles de s\u00e9curit\u00e9. Depuis leur introduction, de multiples vuln\u00e9rabilit\u00e9s dans diff\u00e9rentes couches des protocoles ou des impl\u00e9mentations des protocoles ont \u00e9t\u00e9 trouv\u00e9es et exploit\u00e9es. Pour r\u00e9soudre les probl\u00e8mes de s\u00e9curit\u00e9, de nouvelles versions du protocole sont publi\u00e9es r\u00e9guli\u00e8rement. L’utilisation d’une version plus r\u00e9cente permet de se prot\u00e9ger des failles de s\u00e9curit\u00e9 connues des anciennes versions. Il est donc crucial de r\u00e9agir rapidement en installant les nouvelles versions pour contrer les attaques potentielles.<\/p>\n\n\n\n

Par ailleurs, TLS s’appuie sur des certificats num\u00e9riques pour authentifier un serveur aupr\u00e8s d\u2019une application. Ces certificats doivent \u00eatre \u00e9mis (et sign\u00e9s) par des autorit\u00e9s de certification et ils poss\u00e8dent de multiples caract\u00e9ristiques qui doivent \u00eatre v\u00e9rifi\u00e9es pour qu’un certificat soit valide pour un domaine donn\u00e9. Cependant, il existe un risque car des attaquants peuvent \u00e9mettre des certificats douteux, en apparence s\u00e9curis\u00e9s, ce qui leur permet d\u2019intercepter des communications d\u2019utilisateurs.<\/p>\n\n\n\n

Pour rajouter une couche de s\u00e9curit\u00e9 suppl\u00e9mentaire, il est conseill\u00e9 d\u2019utiliser le \u00ab certificate pinning \u00bb, qui est une m\u00e9thode compl\u00e9mentaire de validation du certificat du serveur. En plus d\u2019effectuer les contr\u00f4les classiques sur le certificat pr\u00e9sent\u00e9 par le serveur, comme valider la cha\u00eene de certification jusqu\u2019\u00e0 un certificat racine ou sa date de validit\u00e9, l\u2019application contr\u00f4le \u00e9galement certaines caract\u00e9ristiques du certificat, comme son num\u00e9ro de s\u00e9rie et la clef publique qui lui est associ\u00e9e. Cette m\u00e9thode pr\u00e9sente l\u2019avantage d\u2019\u00eatre plus robuste que la m\u00e9thode classique, et permet de ne plus d\u00e9pendre que du syst\u00e8me ou des autorit\u00e9s de certification racine pour s\u2019assurer que le certificat pr\u00e9sent\u00e9 est le bon.<\/p>\n\n\n\n

S\u00e9curit\u00e9 des composants tiers<\/h3>\n\n\n\n

La plupart des applications mobiles utilise des composants tiers : librairies, frameworks, API tierces, etc. L\u2019utilisation de ces composants permet de r\u00e9duire consid\u00e9rablement le temps n\u00e9cessaire entre la conception d\u2019une application et sa mise sur le march\u00e9. Ils peuvent cependant repr\u00e9senter un risque de s\u00e9curit\u00e9 important, avec des possibilit\u00e9s de vuln\u00e9rabilit\u00e9s diverses : injections, XSS, mauvaise configuration, etc. <\/p>\n\n\n\n

Nous avons d\u00e9crit les probl\u00e9matiques de s\u00e9curit\u00e9 li\u00e9es \u00e0 l\u2019utilisation des composants tiers dans notre article pr\u00e9c\u00e9dent sur les vuln\u00e9rabilit\u00e9s et attaques courantes des applications web<\/a>. La m\u00eame logique s\u2019applique dans le contexte des applications mobiles. Vous pouvez vous r\u00e9f\u00e9rer \u00e0 cet article pour la s\u00e9curit\u00e9 des composants tiers, ainsi que pour d\u2019autres aspects tels que la s\u00e9curit\u00e9 de l\u2019authentification, les failles logiques\u2026 qui concernent \u00e9galement les applications mobiles.<\/p>\n\n\n\n

R\u00e9aliser un test d\u2019intrusion d\u2019application mobile pour \u00e9valuer et renforcer votre s\u00e9curit\u00e9<\/h2>\n\n\n\n

Un bon moyen de renforcer concr\u00e8tement la s\u00e9curit\u00e9 de vos applications mobiles est de r\u00e9aliser un test d\u2019intrusion. Il s\u2019agit de mettre \u00e0 l\u2019\u00e9preuve votre application en testant m\u00e9thodiquement un p\u00e9rim\u00e8tre pour identifier les failles de s\u00e9curit\u00e9 et proposer les correctifs appropri\u00e9s. <\/p>\n\n\n\n

Un test d\u2019intrusion d\u2019application mobile<\/a> permet de d\u00e9celer des vuln\u00e9rabilit\u00e9s 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\u2019application mobile.<\/p>\n\n\n\n

Exemples de failles c\u00f4t\u00e9 serveur :<\/p>\n\n\n\n