L'Open Web Application Security Project (OWASP) est une organisation mondiale à but non lucratif qui publie fréquemment des informations pratiques sur la sécurité des applications. L'OWASP a publié le "Top 10 Mobile Risks", une liste dédiée à la sécurisation des applications mobiles.
Les pratiques référencées concernent les communications non sécurisées, l'authentification faible, l’altération de code, la rétro-ingénierie, etc. Elles sont classées par exploitabilité, prévalence, détectabilité, impact et s'accompagnent de lignes directrices pour les développeurs mobiles qui cherchent à mieux sécuriser leurs applications. La sensibilisation des développeurs à la sécurité est, bien entendu, l'un des éléments les plus déterminants.
Si elles ne sont pas identifiées et corrigées avant la mise en production, ces 10 vulnérabilités peuvent conduire au vol de données, à la fraude et atteindre la réputation de l’entreprise concernée.
La solution d‘audit de sécurité des applications mobiles Pradeo Security identifie les vulnérabilités OWASP, les classe selon leur niveau de sévérité et fournit des recommandations pour les corriger. Pour en savoir plus sur ce service prêt à l'emploi, cliquez ici.
M1 - Utilisation incorrecte d’une plateforme
Les applications mobiles sont conçues par le biais de programmes de développement qui offrent diverses fonctions de sécurité à intégrer aux applications. Parfois, les développeurs choisissent simplement de n'utiliser aucune de ces fonctionnalités, tandis que certains ne suivent pas forcément la documentation et les configurent maladroitement. Par conséquent, des failles de sécurité sont souvent dues à la non-utilisation ou à la mauvaise implémentation des Intents d'Android, du TouchID ou Keychain d’iOS et d'autres fonctionnalités de sécurité. Pour éviter ceci, il est conseillé aux développeurs de suivre les bonnes pratiques de programmation et de configurer de manière sécurisée le côté serveur des applications.
Exemple : Applications Citrix Worx
M2 - Stockage de données non sécurisé
Cette deuxième catégorie comprend les vulnérabilités qui peuvent entraîner des fuites de données. D’un point de vue sécurité, les applications ne doivent pas être conçues pour stocker des informations sensibles du côté de l'utilisateur final, tel que sur les cartes SD, les fichiers d'applications ou les bases de données SQLite locales, surtout lorsqu'elles ne sont pas chiffrées. En outre, cette catégorie englobe également les mauvaises pratiques tel que l'inscription d'informations sensibles dans les logs, dans la mémoire des applications ou dans son code décompilé, ce qui ne devrait bien sûr jamais être fait.
Exemple : Tinder
M3 - Communication non sécurisée
Une application mobile échange généralement des données avec plusieurs serveurs. Lorsque ces communications sur le réseau ne sont pas chiffrées ni correctement authentifiées (handshake, versions SSL incorrectes, faible négociation, communication avec du texte clair, etc.) Dans le cas d’applications traitant des données à caractère personnel (banques, santé, administrations publiques…), ces vulnérabilités représentent un manquement aux lois sur la protection des données. D’autre part, lorsqu'elles se retrouvent dans des applications liées à des objets connectés (domotique, caméra de sécurité, voitures intelligentes...), elles peuvent conduire à une prise de contrôle.
Exemple : Montres intelligentes défectueuses
M4 - Authentification non sécurisée
Cette catégorie couvre l'authentification des utilisateurs finaux et la mauvaise gestion des sessions. Dans les applications mobiles, contrairement aux applications web, les utilisateurs ne sont pas toujours en ligne. Les applications mobiles doivent donc être capables d'identifier l'utilisateur et de conserver son identification tout au long de sa session, qu'il soit en ligne ou non.
Lorsque les cybercriminels identifient un schéma d'authentification inexistant ou faible dans les applications mobiles, ils créent des logiciels malveillants qui les contournent. Une authentification des utilisateurs selon plusieurs facteurs permet de prévenir les accès frauduleux aux données.
Exemple : Application Android « Grab »
Découvrez les techniques de protection des applications mobiles, du développement à l'exploitation dans notre guide de la sécurité des applications mobiles.
M5 - Cryptographie insuffisante
L'utilisation non sécurisée de la cryptographie est fréquente parmi les applications mobiles utilisant le chiffrement. Elle peut provenir de processus défectueux ou d'algorithmes de chiffrement faibles par nature. Dans les deux cas, un pirate peut exploiter cette vulnérabilité pour déchiffrer les données sensibles traitées par les applications. Pour y palier, les développeurs doivent s'assurer d'appliquer des normes cryptographiques actuelles et pérennes.
Exemple : Envoi de données personnelles non chiffrées
M6 - Autorisation non sécurisée
Après avoir authentifié les utilisateurs, certaines applications accordent par défaut certaines autorisations. Ces autorisations sont parfois, à tort, trop étendues, ce qui donne aux utilisateurs des droits qu'ils ne devraient pas avoir. Si un cybercriminel obtient les droits privilégiés d’une application, il peut accéder illégalement à des informations sensibles, supprimer des systèmes entiers ou prendre le contrôle d'objets connectés. L'éventail des autorisations accordées aux utilisateurs doit être évalué avant que les applications ne soient publiées.
Exemple : Viper smart start
M7 - Qualité du code client
Cette catégorie comprend des vulnérabilités telles que les dépassements de mémoire tampon (buffer overflow), les vulnérabilités de chaîne de caractères formatées et diverses autres erreurs au niveau du code qui permettent l'exécution de code sur les terminaux mobiles. En cas de dépassement de la mémoire tampon par exemple, il est possible d'écrire dans des zones contenant du code exécutable et de le remplacer par du code malveillant, ou d'écraser de manière sélective les données relatives à l'état du programme, provoquant ainsi un comportement qui n'était pas prévu à l’origine par le développeur. La plupart des problèmes de qualité code peuvent être résolus en appliquant de bonnes pratiques. Utiliser les mêmes formes de code à travers une organisation, les rendre faciles à comprendre et les accompagner d'une documentation claire permet de réduire ce risque.
Exemple : WhatsApp
M8 - Falsification de code
La falsification ou tampering consiste à dupliquer une application, à ajouter une ou plusieurs portes dérobées à son code, à la resigner et à la publier dans des magasins d’applications tiers. Les applications falsifiées sont souvent qualifiées de clones malveillants, et ciblent généralement les applications bancaires et les applications très populaires. Grâce aux portes dérobées, les pirates sont capables d'intercepter des données et même parfois de se faire passer pour des applications officielles pour communiquer avec les serveurs des entreprises. Pour prévenir ce risque, les développeurs doivent utiliser des solutions anti-tampering ou doter leurs applications de capacités de détection du tampering.
Exemple : Postbank Finanzassistent (étude de cas à la fin de l'article)
M9 – Rétro-ingénierie
Pour décomposer une application, un attaquant analyse son code binaire afin de déterminer son code source, ses bibliothèques, ses algorithmes, etc. En fournissant une connaissance plus approfondie de l'application, cette technique permet aux hackers d'identifier ses défauts et de les exploiter plus facilement. La rétro-ingénierie peut entraîner le vol de propriété intellectuelle, d'informations sur des serveurs, de clés cryptographiques, etc. Pour minimiser ce risque, les développeurs doivent écrire un code complexe et utiliser des méthodes d'obfuscation.
Exemple : Pokemon Go
M10 - Fonctionnalité externe
Au cours des cycles de développement, les développeurs intègrent souvent des portes dérobées ou des contrôles de sécurité à leurs applications pour détecter et corriger leurs vulnérabilités. Ces fonctionnalités ne sont pas censées rester dans l'environnement de production, mais sont parfois accidentellement oubliées. Lorsqu'elles sont identifiées, ces elles peuvent être exploitées par les pirates pour accéder à des données sensibles ou gagner des droits. Avant de publier une application, les développeurs doivent revoir les configurations et désactiver les logs de débogage.
Exemple : Transfert de fichiers Wifi
