Comprendre les 10 principaux risques de l'OWASP Mobile avec des cas réels

Détenir un record de l'industrie en matière de développement d'applications 100% à l'épreuve du piratage s'accompagne d'une responsabilité et d'une garantie de base qu'aucune des solutions numériques développées sous notre nom ne serait confrontée à une faille de sécurité.

Pour y parvenir, l'équipe d'assurance qualité d'Appinventiv connaît tous les risques de sécurité possibles auxquels une application peut être confrontée. Connaître les risques permet d'ignorer facilement les pièges et d'écrire des applications sécurisées.

Nous aider à être au top en matière de sécurité, c'est avoir une connaissance complète des pratiques de codage sécurisé OWASP (Open Web Application Security Project). Il s'agit d'une communauté en ligne de spécialistes de la sécurité qui ont développé une documentation gratuite, du matériel d'apprentissage et des outils pour créer des applications mobiles et Web sécurisées.

Entre autres choses, ils ont également compilé une liste des 10 principales menaces de sécurité OWASP Mobile dans les applications mobiles.

Bien que le document sur les pratiques de sécurité de l'OWASP soit assez clair, il peut parfois être difficile pour les entreprises de le connecter à partir de cas réels.

Dans cet article, nous vous donnerons un aperçu de base des 10 principaux risques de sécurité mobile et donnerons des exemples des vulnérabilités révélées dans le monde réel pour chacun d'eux. Cela vous donnera un aperçu de ce à quoi nous nous préparons chez Appinventiv lorsque nous travaillons sur votre application.

Avant d'aborder les risques, penchons-nous sur les statistiques.

NowSecure a examiné les applications sur Google Play Store et l'App Store a identifié que plus de 85 % des applications violent l'un des risques.

Parmi ces applications, 50 % avaient un stockage de données non sécurisé et quelque part le même nombre d'applications travaillaient avec un risque de communication non sécurisé . Voici un graphique montrant le pourcentage d'occurrence des risques du Top 10 mobile de l'OWASP

Liste des 10 menaces les plus courantes pour les applications mobiles et les meilleures pratiques pour les éviter

M1 : Utilisation inappropriée de la plate-forme

La catégorie des tests de sécurité OWASP comprend l'utilisation abusive d'une fonctionnalité de l'appareil ou l'instance d'échec lors de l'utilisation des contrôles de sécurité de la plate-forme. Cela peut inclure des autorisations de plate-forme, des intentions Android, une mauvaise utilisation du TouchID, du trousseau, etc.

Cas réel :

Trois applications iOS : "Fitness Balance app", "Heart Rate Monitor" et "Calories Tracker app" sont apparues pour avoir contourné le Touch ID d'Apple. Ils demandaient aux utilisateurs d'utiliser leur empreinte digitale pour obtenir des informations sur la condition physique, alors qu'ils l'utilisaient pour facturer de l'argent sur l'App Store.

Bonne pratique à éviter :

• Le développeur ne doit pas autoriser les cryptages Keychain via la route du serveur et conserver les clés dans un seul appareil, afin qu'il soit impossible d'être exploité sur d'autres serveurs ou appareils.
• Le développeur doit sécuriser l'application via Keychain pour stocker le secret de l'application qui a une liste de contrôle d'accès dédiée.
• Le développeur doit obtenir l'autorisation de limiter les applications autorisées à communiquer avec son application.
• Le développeur doit contrôler le premier de la liste OWASP Mobile Top 10 en définissant les intentions explicites et en bloquant ainsi tous les autres composants pour accéder aux informations présentes dans l'intention.

M2 : Stockage de données non sécurisé

L'OWASP considère qu'il s'agit d'une menace lorsqu'une personne accède à un appareil mobile perdu/volé ou lorsqu'un logiciel malveillant ou une autre application reconditionnée commence à agir au nom de l'adversaire et exécute une action sur l'appareil mobile.

Une vulnérabilité de stockage de données non sécurisée entraîne généralement ces risques :

• Fraude
• Vol d'identité
• Perte matérielle.
• Dégâts de réputation
• Violation de la politique externe (PCI)

Cas réel :

Les applications de rencontres comme Tinder, OKCupid et Bumble ont été à maintes reprises examinées pour leurs pratiques de stockage de données non sécurisées. Les failles de sécurité présentes sur ces applications varient en fonction de la faisabilité, de la gravité et de la faisabilité, peuvent exposer le nom des utilisateurs, les informations de connexion, l'historique des messages et même l'emplacement, en plus d'autres activités de compte personnel.

Bonnes pratiques à éviter :

• Pour iOS, les pratiques de sécurité de l'OWASP recommandent d'utiliser des applications vulnérables spécialement conçues comme iGoat pour modéliser les menaces de leur cadre de développement et de leurs applications. Cela aidera les développeurs d'applications ios à comprendre comment les API traitent les processus d'application et les ressources d'information.
• Les développeurs d'applications Android peuvent utiliser le shell Android Debug Bridge pour vérifier les autorisations de fichier de l'application ciblée et du SGBD pour vérifier le cryptage de la base de données. Ils doivent également utiliser l'outil d'analyse de la mémoire et Android Device Monitor pour s'assurer que la mémoire de l'appareil ne contient pas de données involontaires.

M3 : Communication non sécurisée

Lors de la conception d'une application mobile, les données sont échangées dans le modèle client-serveur. Ainsi, lorsque les données sont transmises, elles doivent d'abord traverser le réseau de l'opérateur de l'appareil et Internet. Les agents de menace pourraient exploiter les vulnérabilités et intercepter des données sensibles tout en voyageant à travers le fil. Voici les différents agents de menace qui existent :

• Adversaire qui partage votre réseau local – un Wi-Fi compromis
• Périphériques réseau ou opérateur - tours cellulaires, proxy, routeurs, etc.
• Logiciels malveillants sur l'appareil mobile.

L'interception de données sensibles via un canal de communication entraînerait une violation de la vie privée, ce qui peut entraîner :

• Vol d'identité
• Fraude
• Atteinte à la réputation.

Cas réel :

La société de sécurité Rapid7 a révélé plusieurs vulnérabilités liées aux montres intelligentes pour enfants. Ces montres étaient commercialisées comme celles utilisées par les parents pour suivre leurs enfants et leur envoyer des messages ou passer des appels sur leur smartwatch.

Les montres étaient censées être contactées par des numéros de contact approuvés via le mode d'une liste blanche, mais la société a constaté que les filtres ne fonctionnaient même pas. Les montres acceptaient même les commandes de configuration par SMS. Cela signifiait qu'un pirate informatique pouvait modifier les paramètres de la montre et mettre les enfants en danger.

"Vous pouvez identifier où se trouve le téléphone ou l'enfant, vous pouvez accéder à l'audio ou passer des appels téléphoniques aux enfants", a déclaré Deral Heiland, responsable de la recherche IoT chez Rapid7.

Bonnes pratiques à éviter :

• Les développeurs doivent non seulement rechercher les fuites sur le trafic communiqué entre l'application et le serveur, mais également l'appareil qui contient l'application et un autre appareil ou réseau local.

• L'application de TLS/SSL pour le transport des canaux est également l'une des meilleures pratiques de sécurité des applications mobiles à prendre en compte lorsqu'il s'agit de transmettre des informations sensibles et d'autres données sensibles.

• Utilisez des certificats fournis par des vérifications de chaîne SSL de confiance.
• N'envoyez pas de données sensibles sur d'autres canaux comme les MMS, les SMS ou les notifications push.
• Appliquez une couche de chiffrement distincte aux données sensibles avant de les transmettre au canal SSL.

M4 : Authentification non sécurisée

Les agents de menace qui exploitent les vulnérabilités d'authentification le font via des attaques automatisées qui utilisent des outils personnalisés ou disponibles.

L'impact commercial de M4 peut être :

• Vol d'informations
• Atteinte à la réputation
• Accès non autorisé aux données.

Cas réel :

En 2019, une banque américaine a été piratée par un cyber-attaquant qui a profité de la faille du site Web de la banque et a contourné l'authentification à deux facteurs mise en place pour protéger les comptes.

L'attaquant s'est connecté au système via les informations d'identification volées de la victime et lorsqu'il a atteint la page où le code PIN ou la réponse de sécurité devait être saisi, l'attaquant a utilisé une chaîne manipulée dans l'URL Web, qui avait défini l'ordinateur comme un ordinateur reconnu. Cela lui a permis de traverser la scène et d'initier les virements.

Bonnes pratiques à éviter :

• L'équipe de sécurité de l'application doit étudier l'authentification de l'application et la tester via des attaques binaires en mode hors ligne pour déterminer si elle peut être exploitée.
• Les protocoles de sécurité de test des applications Web OWASP doivent correspondre à ceux des applications mobiles.
• Utilisez autant que possible les méthodes d'authentification en ligne, comme dans le cas d'un navigateur Web.
• N'activez pas le chargement des données d'application tant que le serveur n'a pas authentifié les sessions utilisateur.
• Les endroits où les données locales nous parviennent, garantissent qu'elles sont cryptées via une clé cryptée dérivée des identifiants de connexion des utilisateurs.
• La demande d'authentification persistante doit également être stockée sur le serveur.
• L'équipe de sécurité doit être prudente avec les jetons d'autorisation centrés sur l'appareil dans l'application, car si l'appareil est volé, l'application peut devenir vulnérable.
• Étant donné que l'accès physique non autorisé aux appareils est courant, l'équipe de sécurité doit appliquer une authentification régulière des informations d'identification de l'utilisateur à partir du serveur.

M5 : Risques de cryptographie insuffisants

Les agents de menace dans ce cas sont ceux qui ont l'accès physique aux données qui ont été chiffrées à tort. Ou lorsqu'un logiciel malveillant agit au nom d'un adversaire.

La cryptographie brisée entraîne généralement ces cas :

• Vol d'informations
• Vol de propriété intellectuelle
• Vol de code
• Violations de la vie privée
• Atteinte à la réputation.

Cas réel :

Il y a quelque temps, une alerte de l'équipe d'intervention en cas d'urgence cybernétique de DHS Industrial Control Systems et l'avis Philips ont averti les utilisateurs d'une vulnérabilité possible dans l' application Android Philips HealthSuite Health .

Le problème, qui a été attribué à une force de cryptage insuffisante, a ouvert l'application aux pirates qui pouvaient accéder à l'activité de fréquence cardiaque, à la pression artérielle, à l'état de sommeil, au poids et à l'analyse de la composition corporelle des utilisateurs, etc.

Bonnes pratiques à éviter :

• Pour résoudre l'un des risques les plus courants de l'OWASP Top 10 Mobile , les développeurs doivent choisir des algorithmes de chiffrement modernes pour chiffrer leurs applications. Le choix de l'algorithme tient compte de la vulnérabilité dans une large mesure.
• Si le développeur n'est pas un expert en sécurité, il doit s'abstenir de créer ses propres codes de cryptage.

M6 : Risques d'autorisation non sécurisée

Dans ce cas, les agents de menace peuvent accéder à l'application de quelqu'un d'autre, généralement via des attaques automatisées qui utilisent des outils personnalisés ou disponibles.

Cela peut entraîner les problèmes suivants :

• Vol d'informations
• Atteinte à la réputation
• Fraude

Cas réel :

Les spécialistes de la sécurité de l'information chez Pen Test Partners ont piraté Pandora , un système d'alarme de voiture intelligent. En théorie, l'application sert à suivre une voiture, à couper le moteur en cas de vol et à la verrouiller jusqu'à l'arrivée de la police.

De l'autre côté de la médaille, un pirate peut détourner le compte et accéder à toutes les données et aux fonctionnalités d'alarme intelligentes. De plus, ils pourraient :

• Suivre les mouvements des véhicules
• Activer et désactiver le système d'alarme
• Verrouiller et déverrouiller les portes de la voiture
• Couper le moteur
• Dans le cas de Pandora, les pirates ont eu accès à tout ce dont on parlait à l'intérieur de la voiture grâce au microphone du système antivol.

Bonnes pratiques à éviter :

• L' équipe QA doit régulièrement tester les privilèges de l'utilisateur en exécutant des jetons de session à faible privilège pour les commandes sensibles.
• Le développeur doit noter que les schémas d'autorisation des utilisateurs tournent mal en mode hors ligne.
• La meilleure façon d'éviter ce risque consiste à exécuter des vérifications d'autorisation pour les autorisations et les rôles d'un utilisateur authentifié sur le serveur, au lieu de l'appareil mobile.

M7 : Risques liés à la mauvaise qualité du code

Dans ces cas, des entrées non fiables sont transmises par des entités à des appels de méthode effectués dans le code mobile. Cela peut avoir pour effet des problèmes techniques pouvant entraîner une dégradation des performances, une utilisation intensive de la mémoire et une mauvaise architecture frontale.

Cas réel :

L'année dernière, WhatsApp a corrigé une vulnérabilité dont les pirates profitaient pour installer un logiciel malveillant de surveillance appelé Pegasus Spyware sur les smartphones. Tout ce qu'ils avaient à faire était de passer un appel audio WhatsApp sur les numéros de téléphone ciblés.

En quelques étapes simples, les pirates ont pu pénétrer dans les appareils des utilisateurs et y accéder à distance.

Bonnes pratiques à éviter :

• Selon les pratiques de codage sécurisé OWASP , le code doit être réécrit dans l'appareil mobile au lieu de le fixer côté serveur. Les développeurs doivent noter qu'un mauvais codage côté serveur est très différent d'un mauvais codage au niveau client. Cela signifie que les contrôles côté serveur faibles et les contrôles côté client doivent faire l'objet d'une attention distincte.
• Le développeur doit utiliser des outils tiers d'analyse statique pour identifier les dépassements de mémoire tampon et les fuites de mémoire.
• L'équipe doit créer une liste de bibliothèques tierces et vérifier périodiquement les nouvelles versions.
• Les développeurs doivent considérer toutes les entrées du client comme non fiables et les valider, qu'elles proviennent des utilisateurs ou de l'application.

M8 : Risques de falsification de code

Habituellement, dans ce cas, un attaquant exploite la modification du code via des formes malveillantes des applications hébergées dans les magasins d'applications tiers. Ils peuvent également inciter les utilisateurs à installer une application par le biais d'attaques de phishing.

Bonnes pratiques à éviter :

• Les développeurs doivent s'assurer que l'application est capable de détecter les changements de code lors de l'exécution.
• Le fichier build.prop doit être vérifié pour la présence d'une ROM non officielle dans Android et pour savoir si l'appareil est rooté.
• Le développeur doit utiliser des sommes de contrôle et évaluer les signatures numériques pour voir si le fichier a été falsifié.
• Le codeur peut s'assurer que les clés, le code et les données de l'application sont supprimés une fois la falsification détectée.

M9 : Risque d'ingénierie inverse

Un attaquant télécharge généralement l'application ciblée depuis l'App Store et l'analyse dans son environnement local avec une suite d'outils différents. Après quoi, ils peuvent modifier le code et rendre le fonctionnement de l'application différent.

Cas réel :

Pokemon Go a récemment été confronté à des failles de sécurité lorsqu'il a été découvert que les utilisateurs avaient procédé à une ingénierie inverse de l'application pour connaître le voisinage des Pokémons et les attraper en quelques minutes.

Bonnes pratiques à éviter :

• La meilleure façon de protéger une application contre le risque, selon la sécurité mobile OWASP , est d'utiliser les mêmes outils que les pirates utiliseraient pour l'ingénierie inverse.
• Le développeur doit également obscurcir le code source afin qu'il devienne difficile à lire, puis faire de l'ingénierie inverse.

M10 : Risque lié aux fonctionnalités externes

Habituellement, un pirate informatique examine les fonctionnalités superflues à l'intérieur d'une application mobile afin de découvrir les fonctionnalités cachées dans les systèmes dorsaux. L'attaquant exploiterait des fonctionnalités étrangères à partir de ses propres systèmes sans aucune implication des utilisateurs finaux.

Cas réel :

L'idée de l'application Wifi File Transfer était d'ouvrir le port sur Android et d'autoriser les connexions depuis l'ordinateur. Le problème ? Une absence d'authentification telle que des mots de passe, ce qui signifie que n'importe qui peut se connecter à un appareil et obtenir son accès complet.

Bonnes pratiques à éviter :

• Assurez-vous qu'il n'y a pas de code de test dans la version finale
• Assurez-vous qu'il n'y a pas de commutateur caché dans les paramètres de configuration
• Les journaux ne doivent contenir aucune description de processus de serveur principal
• Assurez-vous que les journaux système complets ne sont pas exposés aux applications par les OEM
• Les points de terminaison de l'API doivent être bien documentés.