Blog

Top 8 des vulnérabilités du code mobile et comment les éviter

vulnérabilités du code mobile

De nos jours, le code mobile est dans les poches de presque tout le monde. Presque tout le monde porte un téléphone portable avec soi. Et comme les applications antivirus pour appareils mobiles sont rares (voire inexistantes pour les utilisateurs iOS), de nombreuses personnes pensent que les appareils mobiles ne sont pas confrontés à autant de risques que leurs homologues de bureau (ou portables). Mais même si les enjeux peuvent différer, ils sont bien réels et, avec le temps, ils pourraient même devenir plus omniprésents que ceux associés à l’informatique traditionnelle.

Dans cet article, nous examinons les sept principales menaces liées aux codes mobiles et fournissons des informations sur la manière de les atténuer.

1 – Utilisation abusive intentionnelle ou non de la plateforme

Quelle que soit la marque de l'appareil mobile que vous utilisez, iOS ou Android, les deux plates-formes fournissent des directives de développement aux développeurs d'applications. Beaucoup de ces directives sont liées à la sécurité. Cependant, de nombreux développeurs d’applications enfreignent involontairement les directives de la plateforme en raison d’une erreur humaine. Et certains développeurs d’applications peuvent le faire délibérément.

Qu’elle soit intentionnelle ou non, cette menace se résume à une mauvaise utilisation d’une fonctionnalité de la plateforme iOS ou Android ou à l’échec de la mise en œuvre des contrôles de sécurité de la plateforme. Et ils peuvent entraîner les problèmes suivants :

  • Utilisation abusive des fonctionnalités Touch ID ou Face ID d'iOS, pouvant entraîner un accès non autorisé.
  • Utilisation inappropriée du trousseau sécurisé d’iOS en stockant les clés de session dans le stockage de l’application (plutôt que dans le trousseau), ce qui pourrait compromettre la session de l’utilisateur.
  • Une application demandant des autorisations excessives ou inappropriées pourrait entraîner élévation de privilèges , accordant potentiellement à l’application l’accès à plus de données de l’appareil qu’elle ne le devrait.
  • Les intentions Android, qui sont utilisées pour inciter à une action ou demander des données à une autre application sur l'appareil, pourraient révéler des informations sensibles ou permettre un accès non autorisé à l'appareil si elles sont marquées comme publiques.

Atténuations

  • Les plateformes devraient mettre en œuvre bac à sable , ce qui restreint la capacité d’une application à communiquer avec d’autres applications (c’est déjà le cas sur iOS). Les plates-formes doivent également implémenter des autorisations de fichiers par défaut restrictives.
  • Du côté des développeurs, les développeurs doivent appliquer la classe la plus restrictive pour les trousseaux iOS et adhérer strictement aux meilleures pratiques de la plate-forme pour éviter une mise en œuvre faible de tout type de fonctionnalité.

2 – Stockage de données non sécurisé

Les applications peuvent stocker des données. Et si ces données ne sont pas suffisamment protégées, elles pourraient être accessibles en cas de perte ou de vol de votre téléphone. Même sans perdre votre appareil, des logiciels malveillants pourraient se retrouver sur votre appareil et si vos données ne sont pas correctement sécurisées, ces logiciels malveillants pourraient les transmettre aux attaquants.

Bien entendu, l’atténuation à toute épreuve du stockage de données non sécurisé consiste pour l’application à ne stocker aucune donnée. Mais cela n’est peut-être pas réalisable pour de nombreuses applications, sinon la plupart. Ainsi, en tant que développeur, il est acceptable d’avoir les données utilisateur de votre boutique d’applications, à condition de suivre les directives ci-dessous.

Atténuations

  • Supposons que chaque téléphone sur lequel votre application est installée est jailbreaké/rooté. Bien qu’il n’y ait rien de mal en soi à jailbreaker ou à rooter votre téléphone (si vous savez ce que vous faites), cela présente moins d’avantages que jamais. Et les utilisateurs moins expérimentés pourraient ne pas comprendre les implications de sécurité du jailbreak/rooting. Il contourne le sandboxing du système d’exploitation et fournit un accès complet au système de fichiers. Dans de nombreux cas, un téléphone jailbreaké/rooté contournera également le cryptage par défaut du téléphone. En bref, ne présumez pas que les utilisateurs n’auront pas accès au système de fichiers et créerez vos applications en conséquence.
  • Lorsque vous créez votre application, assurez-vous de bien comprendre si chiffrement est correctement appliqué dans les emplacements de fichiers pertinents pour votre application et que vous comprenez également comment les clés de cryptage sont protégées et où elles sont stockées.
  • Essayez de renforcer votre code contre la falsification en implémentant l'obscurcissement, la protection contre débordements de tampon , etc.
  • Évitez de stocker/mettre en cache les données autant que possible.

3- Communication et transfert de données non sécurisés

Une communication non sécurisée pourrait divulguer des informations sensibles même si l'application elle-même était conçue conformément aux directives de la plateforme. Des choses comme les attaques de l’homme du milieu et le contournement de l’authentification deviennent possibles si l’application qui lance la communication avec un serveur distant ne dispose pas des garanties d’authentification et de chiffrement appropriées. Si ces garanties sont cruciales dans pratiquement tous les contextes, elles deviennent absolument essentielles dans le contexte des applications d’achat et bancaires, par exemple.

Atténuations

  • Mettre en œuvre TLS/HTTPS pour toute communication sur le web.
  • Il est également recommandé de mettre en œuvre l’épinglage de certificat, une méthode supplémentaire de validation du certificat du serveur qui ajoute une couche de sécurité supplémentaire. En plus d'effectuer les vérifications par défaut du certificat présenté par le serveur, comme valider la chaîne de certificats vers un certificat racine. Avec l'épinglage du certificat, l'application vérifiera également d'autres caractéristiques du certificat, telles que son numéro de série et sa clé publique. L'épinglage de certificat est plus robuste que la méthode traditionnelle dans la mesure où il n'est plus nécessaire de s'appuyer uniquement sur les autorités de certification (CA) pour valider le certificat.
  • Codez votre application pour avertir les utilisateurs si un certificat SSL/TLS non valide est détecté ou si le processus de vérification de la chaîne de certificats échoue.

4 – Échec du nettoyage des entrées de l’utilisateur

Si votre application permet une saisie utilisateur qui interagit avec votre backend (serveur distant) sans une désinfection appropriée appliquée à cette entrée, vous ouvrez la porte à diverses attaques :

Si le contenu utilisateur peut être téléchargé sur votre serveur sans validation – pensez aux commentaires ou avis des utilisateurs – alors des acteurs malveillants pourraient télécharger des scripts malveillants dans les commentaires/avis. Une fois téléchargés, ils seraient renvoyés aux utilisateurs sans méfiance atteignant cette page. Le navigateur de l’utilisateur exécuterait automatiquement les scripts car il les considérerait comme provenant d’une source fiable, et vous risqueriez d’être victime des attaques répertoriées ci-dessus.

Atténuations

  • La principale atténuation sera quelque peu évidente : si vous autorisez la saisie des utilisateurs dans votre application, nettoyez-la.
  • Considérez que toutes les entrées des utilisateurs ne sont pas fiables. Traitez les entrées de tous les utilisateurs de la même manière, qu’il s’agisse d’utilisateurs authentifiés, d’utilisateurs internes ou d’utilisateurs publics : ne leur faites pas confiance.
  • Définissez l'indicateur HttpOnly. La définition de cet indicateur garantit que les cookies ne seront pas accessibles via JavaScript côté client (comme dans notre exemple de vol de cookies ci-dessus), uniquement via HTTP.
  • Assurez-vous de configurer des vérifications de liste blanche lorsque vous travaillez avec des fichiers ou des répertoires provenant d'une entrée contrôlée par l'utilisateur.

5 – Authentification non sécurisée

Il est essentiel d’obtenir une authentification correcte lors du codage d’une application. Avant d'accorder l'accès à l'utilisateur, une application (mobile ou autre) doit authentifier l'utilisateur. Mais de nombreuses vulnérabilités peuvent permettre à un attaquant de contourner le mécanisme d'authentification. Des choses comme autoriser le backend API les demandes de service sans nécessiter de jeton d'accès, le stockage des mots de passe localement sur l'appareil ou l'autorisation de définir des mots de passe faibles sont autant de choses qui peuvent rendre les mécanismes d'authentification d'une application mobile vulnérables au contournement. Un attaquant exploitant ces vulnérabilités pourrait effectuer une attaque d’élévation de privilèges, conduisant à un vol de données sensibles et à d’autres bonnes choses…

Atténuations

  • Évitez les méthodes d’authentification locales. Il est préférable de déléguer cette responsabilité au serveur distant. Il doit être configuré de manière à autoriser le téléchargement des données d'application uniquement après une authentification réussie.
  • N'utilisez pas de méthodes d'authentification faibles, telles que l'identité de l'appareil. Forcer l'utilisation de authentification multifacteur (MAE).

6 – Cryptographie faible ou mal implémentée

Le titre de cette section raconte assez bien l’histoire. Les deux principaux facteurs qui peuvent compromettre le cryptage de votre appareil et révéler des informations sensibles sont :

  1. L'utilisation d'algorithmes de cryptage faibles
  2. Des failles dans la mise en œuvre du processus cryptographique

Ce qui précède peut se produire pour de nombreuses raisons différentes, notamment :

  • Les paramètres de chiffrement ne sont pas correctement codés en dur dans l’application, ce qui entraîne un contournement potentiel.
  • Les clés de chiffrement sont mal gérées.
  • L'utilisation d'algorithmes de chiffrement et de hachage personnalisés (non évalués par les pairs) ou d'algorithmes de chiffrement et de hachage obsolètes, tels que MD5 et SHA1.

Atténuations

  • Utilisez uniquement des normes cryptographiques strictes et des protocoles de cryptage recommandés par le National Institute of Standards and Technology (NIST).
  • Stockez uniquement les données sensibles (telles que les clés de chiffrement) dans l’enclave sécurisée de l’appareil, qui n’est accessible qu’aux processus protégés. Sauf cela, évitez simplement de stocker des informations sensibles sur l’appareil autant que possible.

7 – Autorisation non sécurisée

Ce point est lié au point 5 : authentification non sécurisée. L'authentification et l'autorisation sont deux choses différentes. Cependant, l’un implique l’autre. L’authentification détermine les autorisations de chacun. Nous parlons ici des autorisations des utilisateurs. Une fois que vous vous êtes authentifié, votre utilisateur se voit attribuer des autorisations pour accéder à des emplacements réseau et à des fichiers spécifiques. Mais comme nous le savons, tous les utilisateurs ne sont pas égaux. Listes de contrôle d'accès (ACL) sont utilisés pour définir les autorisations de chaque utilisateur sur le réseau. Le compte utilisateur de votre réceptionniste n’a probablement pas besoin d’accéder aux fichiers liés à la paie.

Cependant, des systèmes d’autorisation mal mis en œuvre peuvent légitimement vérifier l’identité d’un utilisateur sans parvenir à valider son niveau d’autorisation. Votre système d'autorisation doit renforcer l'identité ainsi que les autorisations. Dans le cas contraire, les utilisateurs légitimes et les pirates informatiques auront accès à des informations sensibles et ouvriront la porte à des attaques par élévation de privilèges.

Atténuations

Validez et appliquez les autorisations accordées à un utilisateur authentifié en référençant les informations présentes sur les systèmes backend (le(s) serveur(s) d'autorisation) plutôt que d'utiliser les informations (identifiants) fournies par l'appareil mobile. Et vous voulez vous assurer que cela se produit pour chaque utilisateur.

8 – Qualité générale du code

Le huitième point est en quelque sorte une catégorie générique pour divers problèmes de code mobile concernant un codage incorrect des applications clientes que nous installons sur nos smartphones et tablettes.

Le codage d’une application est un travail complexe et détaillé. Un seul caractère supplémentaire dans le code peut entraîner un comportement indésirable au sein de l'application. Et certains de ces comportements involontaires peuvent être dangereux et exposer vos données sensibles à des acteurs malveillants. De mauvaises pratiques de codage peuvent ouvrir la porte à toutes sortes de vulnérabilités exploitables.

En plus de cela, de nombreuses applications (la plupart d'entre elles ?) s'appuient sur des bibliothèques et des SDK tiers pour créer leurs applications plus rapidement et plus facilement. Cela peut faire gagner du temps au développeur d’applications dans la mesure où les SDK tiers intègrent nativement les fonctionnalités sans obliger le développeur à coder explicitement cette fonctionnalité – le SDK s’en charge.

Cependant, ces SDK et bibliothèques peuvent contenir des bogues et n'ont peut-être pas été testés de manière adéquate. Vous êtes à la merci du contrôle qualité de leurs fournisseurs lorsque vous utilisez des outils tiers, car vous n’êtes pas propriétaire du code. Et la plupart du temps, lorsqu’une application héberge des bogues au niveau du code, la seule solution consiste à réécrire une partie du code et à proposer une mise à jour de l’application aux utilisateurs.

Les bogues au niveau du code dans les applications mobiles peuvent conduire à :

Atténuations

Les atténuations ici sont simplement des mesures générales de bon sens pour tout environnement de développement :

  • Assurez-vous de tester les débordements de tampon, fuites de mémoire , etc. à l'aide d'outils automatisés
  • Effectuez des révisions du code source et efforcez-vous d’écrire un code facile à comprendre, cohérent dans toute l’organisation et documentez correctement votre code.

Conclure

Alors voilà. Les vulnérabilités du code mobile constituent une menace très répandue. Et cette menace ne fera que croître à mesure que les appareils mobiles continueront de supplanter les appareils informatiques plus traditionnels. Et nous devrions vraiment prêter attention aux vulnérabilités du code mobile, car les appareils mobiles ont tendance à fournir moins de contrôle à l'utilisateur que les plates-formes informatiques plus traditionnelles. Vous devez donc vraiment être conscient de ce à quoi vous vous exposez lorsque vous utilisez un appareil mobile.

Espérons que les mesures d’atténuation énumérées ci-dessus vous aideront à cet égard.

Comme toujours, restez en sécurité.

^