Sécurité des applications mobiles : Comment la garantir ?

Que recherchent les attaquants dans nos appareils mobiles ?

• Accès aux identifiants
• Données personnelles (adresses, informations de carte de crédit, localisation…)
• Accéder au stockage de données de l'application
• Réaliser de l'ingénierie inverse pour localiser des vulnérabilités, des identifiants intégrés ou des algorithmes générant des clés
• Installation de logiciels malveillants ou blocage de fonctions existantes
• Accéder à l'appareil et contrôler les connexions
• Etc.

Comme nous pouvons le constater, doter notre application de mécanismes de sécurité empêchant la réalisation des actions précédentes devient indispensable.

Blindage des applications mobiles : pourquoi n'est-ce pas courant ?

La principale raison est que les développeurs insistent sur le bon fonctionnement des applications sur une large gamme d'appareils, qu'elles répondent à toutes les exigences définies… et se concentrent surtout sur des aspects plus attrayants pour l'utilisateur tels que l'ergonomie, l'expérience utilisateur et l'interface graphique.

Cependant, il est essentiel de prendre conscience que mettre en œuvre des mécanismes de sécurité dans une application mobile est tout aussi important, surtout compte tenu du grand nombre d'utilisateurs potentiels.

En fait, de plus en plus d'entreprises exigent que leurs applications passent par un processus de piratage éthique, qui consiste à pirater un système pour identifier et réparer d'éventuelles vulnérabilités, ce qui prévient efficacement l'exploitation par des pirates malveillants.

Mesures de base en matière de sécurité pour les applications mobiles

Lorsque nous développons notre application mobile, nous devons nous concentrer sur plusieurs domaines et respecter une série d'exigences dans chacun d'eux. Pour cela, nous pouvons nous baser sur la norme de sécurité des applications mobiles OWASP, qui prévoit des exigences pour les architectes et les développeurs de logiciels cherchant à développer des applications mobiles sécurisées.

Ce guide définit 2 niveaux de vérification de sécurité, ainsi qu'un ensemble d'exigences de résistance à l'ingénierie inverse.

Le choix du niveau dépendra du contexte de notre application. Le niveau L1 contient des exigences de sécurité génériques recommandées pour toutes les applications mobiles. Le niveau suivant, L2, est axé sur les applications qui traitent des données hautement sensibles (secteur financier, industrie de la santé).

Nous spécifions ci-dessous les exigences de sécurité les plus remarquables que nous devrions prendre en compte dans le développement de notre application, classées en sept domaines, bien que nous puissions trouver la liste complète dans le guide OWASP lui-même :

Stockage de données et confidentialité

La protection des données sensibles, telles que les identifiants et les informations privées, est non seulement une obligation légale, mais aussi un aspect critique de la sécurité mobile.

Certains des exigences qui permettent de prévenir l'accès à ces informations sont les suivantes :

• Ne pas stocker d'informations sensibles dans le stockage local de l'appareil, et si nécessaire, celles-ci doivent être chiffrées en utilisant une clé dérivée du matériel de stockage sécurisé, qui nécessite une authentification préalable.
• Ne pas écrire d'informations sensibles dans les journaux du système ni dans les copies de sauvegarde.
• Ne pas exposer d'informations sensibles telles que des mots de passe ou des numéros de carte via l'interface utilisateur (IU) ou des captures d'écran, et désactiver le cache du clavier dans les champs de texte contenant ces informations.

Utilisation des clés cryptographiques

Pour protéger les informations sensibles stockées sur notre appareil, la cryptographie est un élément fondamental. Lors de l'utilisation de clés cryptographiques, nous devons prendre en compte les exigences suivantes :

• Ne pas dépendre uniquement de la cryptographie symétrique dont les clés se trouvent directement dans le code source de l'application.
• Ne pas réutiliser une même clé cryptographique pour plusieurs usages.
• Les valeurs aléatoires sont générées en utilisant un générateur de nombres aléatoires suffisamment sécurisé.

Authentification et contrôle des sessions

Pour qu'une application soit sécurisée, elle doit disposer d'un mécanisme d'authentification et de contrôle de la session utilisateur. Bien qu'il soit vrai que la majorité de cette logique se trouve côté serveur, nous indiquons ci-dessous quelques exigences à prendre en compte :

• L'authentification biométrique, si elle existe, n'est pas associée à des événements (par exemple en utilisant une API qui retourne simplement "true" ou "false"), mais basée sur le déverrouillage du keychain/keystore (stockage sécurisé).
• Pour les applications qui gèrent des informations très sensibles, appliquer des mécanismes de double facteur d'authentification.
• Les sessions et les jetons doivent expirer après une période prédéfinie d'inactivité de la part de l'utilisateur.

Communication avec les services

Un aspect important dans les applications est de garantir la sécurité de la communication avec le serveur, en assurant la confidentialité et l'intégrité des données échangées. Pour cela, certains prérequis sont :

• Les informations sont envoyées chiffrées en utilisant le protocole TLS.
• L'application vérifie le certificat X.509 du système distant lors de l'établissement du canal sécurisé et n'accepte que les certificats signés par une CA de confiance.
• L'application utilise son propre magasin de certificats ou effectue le pinning du certificat ou de la clé publique du serveur.

Interaction avec la plateforme mobile

L'interaction entre les applications et les systèmes d'exploitation doit être réalisée en tenant compte des aspects suivants :

• L'application nécessite la quantité minimale de permissions nécessaires.
• L'application n'expose aucune fonctionnalité sensible via des mécanismes IPC sauf si ces mécanismes sont dûment protégés
• Désactiver JavaScript des Webviews sauf si nécessaire.
• Les WebViews sont configurés pour permettre le minimum de schémas (idéalement, seulement https). Des schémas dangereux comme file, tel et app-id sont désactivés.

Qualité du code

Bien que les applications ne soient pas aussi vulnérables aux attaques de type Cross-Site Scripting, les développeurs doivent suivre un guide de bonnes pratiques pour que le code soit sécurisé :

• L'application doit être signée et fournie avec un certificat valide, ainsi que publiée en mode release.
• L'application capture et gère correctement les éventuelles exceptions.
• Les fonctionnalités de sécurité gratuites des outils, telles que la minification du byte-code, la protection de la pile, le support PIE et le comptage automatique des références, sont activées.
• Utiliser des outils permettant d'analyser le code source pour détecter d'éventuelles vulnérabilités comme par exemple SonarQube.

Mécanismes contre la manipulation et l'ingénierie inverse

Nous devons empêcher un attaquant de manipuler notre application ou de réaliser l'ingénierie inverse du code. Pour cela, il existe plusieurs mécanismes à mettre en œuvre :

• Signature de l'application : L'une des techniques de sécurité les plus importantes sur Android est la signature des applications en utilisant des clés publiques et privées.

Lors de la compilation d'une application avec tous les éléments qui la composent (textes, graphiques, code...), chaque développeur doit la sécuriser avec son certificat afin que la signature identifie l'application et qu'il soit possible de savoir si elle a été modifiée ou si elle reste intacte. C'est la seule façon de savoir si une application est fausse ou authentique : dans le cas où la signature a été modifiée, si elle en a une, elle ne correspondra pas au développeur original.

• Anti-Tamper : Les techniques anti-tamper rendent difficile pour un attaquant de modifier un logiciel, en réalisant une ingénierie inverse et en validant son intégrité pour une utilisation modifiée ultérieure. Pour cela, il est vérifié que la signature de l'application est l'originale et des mécanismes de vérification du checksum sont appliqués.
• Obfuscation du code : L'obfuscation du code permet de compacter, d'optimiser et de rendre le code illisible en renommant sémantiquement les classes, les champs, les méthodes et les noms. Le résultat est une application plus petite et plus complexe à réaliser une ingénierie inverse dessus, rendant la compréhension de celle-ci plus difficile aux yeux malveillants.
• Vérification de l'origine de l'installateur : Cette technique permet de vérifier que l'application a été distribuée depuis une source fiable, évitant ainsi d'avoir sur notre terminal une copie de l'apk qui pourrait être infectée par un malware.
• Anti-Debug : Les techniques anti-debug compliquent ou détectent le débogage d'une application, dans le but de pouvoir appliquer certaines actions qui empêchent un attaquant de continuer le processus. Le mécanisme le plus simple est à travers une propriété dans le propre manifeste de l'application, bien qu'il soit recommandé de vérifier dynamiquement et à plusieurs points si le débogage a lieu ou non.
• Anti-Émulateur : Si notre application s'exécute sur un émulateur en dehors du processus de développement, cela indique que quelqu'un d'autre que nous essaie d'analyser l'application. Par conséquent, une bonne pratique consiste à vérifier que dans une version de release, l'application n'est pas accessible via un émulateur qui faciliterait l'attaque de sa sécurité.
• Anti-Root : Il faut éviter autant que possible qu'une application s'exécute sur des terminaux rootés, car ce sont des terminaux beaucoup plus vulnérables et qui permettent l'accès à la mémoire réservée du système et de l'application, compromettant ainsi la persistance et donc la confidentialité des données manipulées.
• Anti-Clone : mécanisme pour éviter que l'application puisse être clonée, à cet égard, les propriétés appropriées seront définies pour éviter de faire une copie de l'application installée et d'obtenir le binaire qu'un éventuel attaquant pourrait utiliser pour appliquer des techniques d'ingénierie inverse.
• Appareil fiable : Google dispose d'une API anti-abus (SafetyNet Attestation API), qui permet d'évaluer si l'appareil Android sur lequel une application est exécutée est fiable.

Conclusion

Chaque jour, nous utilisons de plus en plus d'applications mobiles et celles-ci stockent de plus en plus d'informations sensibles sur l'utilisateur. Il est donc très important de se tenir au courant des nouvelles mesures de sécurité qui apparaissent et de les appliquer de manière proactive à nos développements. L'objectif ne doit pas seulement être que l'utilisateur interagisse avec une bonne UX, mais qu'il le fasse également en toute sécurité.

“Être conscient des vulnérabilités, c'est déjà la moitié de la sécurité”.