Le type d'exigences de sécurité que vous avez en premier lieu n'est pas clair et il est donc difficile de savoir si vos mesures de sécurité sont suffisantes ou non.

Il n'est pas possible de se protéger complètement contre un utilisateur malveillant utilisant votre application tant que vous ne pouvez pas contrôler entièrement l'appareil de l'utilisateur. Ce risque inclut l'exécution de l'application sur des émulateurs, mais inclut également son exécution sur un appareil enraciné ou autrement falsifié - et tout cela ne sera pas détecté par la méthode de détection de racine que vous utilisez.

Au lieu de cela, vous devez concevoir votre application afin qu'un utilisateur malveillant ne puisse pas nuire à vous ou à d'autres utilisateurs mais uniquement à lui-même. Cela signifie par exemple avoir des secrets spécifiques à l'utilisateur dans l'application et ne pas utiliser de secrets globaux. Cela signifie également que vous ne devez faire confiance à rien des rapports de l'application, mais plutôt vérifier si cela a du sens (c'est-à-dire ne pas faire confiance à un score élevé auto-déclaré dans les jeux ou similaire).

De quelle sécurité vous préoccupez-vous ici et qu'essayez-vous de protéger? Essayez-vous de protéger les utilisateurs contre l'accès d'autres personnes à leurs données ou essayez-vous de protéger l'entreprise contre les rétro-ingénieurs qui tentent d'examiner le fonctionnement de l'application parce que votre API n'est pas sécurisée?

Si vous êtes visant uniquement à protéger la sécurité des utilisateurs, il n'y a aucun problème avec l'exécution de l'application dans une machine virtuelle, sauf si vous pensez que les utilisateurs exécuteront l'application dans une machine virtuelle mal sécurisée et se feront voler leurs données, ce qui est à la fois très improbable et est leur problème, pas le vôtre.

Si vous essayez d'empêcher les gens de faire de la rétro-ingénierie de l'application, vous menez une bataille difficile car les vérificateurs de racine sont facilement contournés. C'est aussi presque toujours un effort inutile car l'application ne devrait avoir rien d'utile pour un attaquant si elle a été conçue de manière sécurisée.

De plus, gardez à l'esprit que parfois, les testeurs de sécurité peuvent parfois simplement résoudre des problèmes si ils ne parviennent pas à trouver de véritables problèmes car un rapport vierge rend difficile la justification de l'argent dépensé. Si possible, défiez-les sur cette déclaration et demandez-leur de donner un exemple concret de la façon dont cela est réellement un problème.

La réponse classique et correcte à votre client est NOTANISSUE

Aucun logiciel côté client * * ne devrait jamais être considéré comme sécurisé , dans le sens que pose votre question. Ils ne peuvent pas l'être. Le logiciel côté client - que ce soit le Web ou l'application - est totalement sous le contrôle du client, tout comme son environnement, tout comme la capacité totale de réécrire / modifier le logiciel, ou de l'exécuter sur un environnement indétectablement non sécurisé ou modifié. Ce n'est pas un bug. C'est inhérent au modèle * *.

Je suis réaligné entre les lignes ici, mais je pense voir d'où vient le chercheur.

Votre application n'a aucune entreprise stockant (ou utilisant) des secrets qui pourraient exposer les données d'autres

concevez votre backend de sorte que les secrets donnés au frontend ne donnent qu'un accès compartimenté aux services backend. puis si un utilisateur roote son appareil, il ne peut pirater que son propre compte.

Je ressens le besoin de plaider en faveur du pauvre testeur de stylo décrié ici.

Qu'est-ce que ce testeur a été embauché pour faire et dans quelle mesure?

Si le développeur de l'application a fourni un livre blanc ou stratégie de sécurité, etc. qui prétend que la détection de racine fait partie de leur stratégie de sécurité, alors il est absolument approprié de souligner que la détection de racine est une fiction pour les apks accessibles au public. Ce n'est généralement pas le problème du testeur de déterminer si l'architecture globale est réellement vulnérable côté client et ne devrait être exécutée que sur des périphériques contrôlés, ou si la direction voulait simplement la plus grande liste possible de «fonctionnalités de sécurité». Il ou elle signale simplement qu'il a échoué par rapport aux revendications fournies (que la détection de racine améliore la sécurité.)

Le "correctif" consiste à cesser de prétendre que les vérifications de l'environnement côté client font tout pour la sécurité afin que vous puissiez avoir un liste plus grande de "fonctionnalités de sécurité".

Le libellé qui implique que cette personne a dit "être sur le Playstore est une vulnérabilité" n'est pas le leur. (ayant eu des choses que j'ai dites incorrectement reformulées d'une manière qui les rend assez fausses dans ma propre carrière ...!)

Je ne considérerais aucune des applications côté client ou Web comme autonomes suffisamment sûres, c'est-à-dire sans sécuriser la solution côté serveur indépendamment sur le système d'exploitation.

Toutes les couches de sécurité, toutes les validations et tous les contrôles implémentés dans l'application côté client doivent être au moins répétés avec des validations correspondantes ou plus fortes dans les composants côté serveur d'applications.

De plus, l'utilisation de l'émulateur pour exécuter l'application signifie que les propres vulnérabilités de l'émulateur peuvent nuire à la sécurité de l'utilisateur, par exemple, certaines vulnérabilités ont permis aux attaquants d'exécuter du code à distance, de divulguer des informations, de voler des sauvegardes et des données, ainsi que d'accéder aux fonctions de communication inter-processus de l'émulateur * .

* Source: https://www.bleepingcomputer.com/news/security/bluestacks-flaw-lets-attackers-remotely-control-android-emulator/

Il y a peu de différence entre une JVM exécutée sur un périphérique matériel ou un émulateur. Bien sûr, on pourrait voir si la chaîne de construction du système d'exploitation a "générique" (que seul l'émulateur a), puis quitter l'application, quand il s'agit d'une version de version - mais cela ne fournit aucune amélioration de la sécurité globale (puisque le bytecode peut facilement être décompilé - et seule la signature du code empêche les modifications de fonctionnalité dans une certaine mesure). En outre, les versions de version ne sont pas configurées en tant que débuggable.

Le fait est que lorsqu'il ne peut pas fonctionner sur un périphérique enraciné, il ne fonctionnera pas sur un émulateur (enraciné).

Une détection fiable de la racine est impossible, en raison de trous de test logiques évidents.

Si l'utilisateur a accès à l'apk, l'utilisateur peut également simplement analyser l'apk puis appeler directement l'API de votre serveur assez facilement et contourner complètement l'application ou porter l'application vers un autre système. Vous devez repenser votre approche globale de la sécurité si cela fait partie de la stratégie de protection de vos systèmes pour détecter s’il est exécuté sur un appareil enraciné - puisque vous ne pouvez même pas savoir de manière fiable ce qui est exécuté.

L'utilisateur peut, s'il le souhaite, décompiler votre application et simplement supprimer toutes les parties de détection de l'application en premier lieu. Le processus serait exactement le même que le logiciel de "cracking".

Ce que vous pouvez faire avec la détection de racine est simplement de faire savoir à un utilisateur que vous pensez que son téléphone est enraciné, comme une mise en garde de sécurité pour le utilisateur - peut-être que le téléphone est rooté sans que l'utilisateur le sache? mais même dans ce cas, vous ne pouvez pas vous y fier. vous ne pouvez pas savoir si c'est du matériel réel ou non sur lequel vous utilisez. Vous ne pouvez pas savoir s'il fonctionne sur un système comme Knox où vous pouvez payer Samsung pour obtenir essentiellement des pouvoirs root dans le système (via la fonctionnalité d'entreprise - et oui, il peut essentiellement vous accorder des pouvoirs presque rootés pour jouer avec d'autres applications et d'autres composants d'applications. - le téléphone apparaîtra comme knox sécurisé même alors et non enraciné).

La détection de racine et de tels finissent généralement dans une application pour dissuader le piratage, mais c'est à 100% la mauvaise approche pour lutter contre le problème. Désolé, mais ce dont vous avez besoin, c'est d'un changement de pensée culturelle dans l'organisation en ce qui concerne la sécurité: vous ne pouvez pas faire confiance à un logiciel qui s'exécute ailleurs pour être ce que vous pensez qu'il est si repensant car c'est inutile.

edit: Si vous avez besoin d'un moyen de l'expliquer à vos supérieurs, vous pouvez essayer ceci: "Si nous pouvions faire cela, alors ce morceau de code vaudrait plus que la société entière ne vaudra jamais" - et cette citation s'appliquerait toujours à votre entreprise même si vous travailliez pour Google.

L'avertissement du chercheur en sécurité est correct, mais vous devez placer cet avertissement dans le contexte de votre application pour savoir s'il est pertinent.

Vous avez répertorié la "détection de racine" comme une fonctionnalité de sécurité importante de votre app.

Étant moi-même un expert en sécurité, je voudrais souligner que la détection de racine peut être facilement contournée. Non seulement sur les machines virtuelles: mais également sur les périphériques physiques. De nombreux frameworks qui prétendent faire de la détection de racine ne détectent pas de nombreux périphériques enracinés et détectent certains périphériques normaux comme rootés. Même si c'était le cas, le côté client de n'importe quelle application peut être facilement rétro-conçu. Un attaquant motivé pourra accéder à votre interface back-end en contournant complètement l'application côté client. Cela signifie que tous les contrôles côté client peuvent être contournés et que tout calcul peut être perturbé. Aucun contrôle ou calcul côté client ne peut être fiable.

Il est possible de créer un client de confiance, mais cela nécessite du matériel propriétaire, un système d'exploitation et des logiciels propriétaires. Les consoles de jeux et les réseaux câblés le font, mais souffrent encore beaucoup du piratage, ce qui devrait être un bon exemple de la difficulté à protéger un appareil. Cette stratégie est théoriquement possible, mais échoue sur la pratique car elle est trop chère, voler et empêcher les investissements sur la fonctionnalité du produit qui devient faible et obsolète face à sa concurrence.

À quel point doit-elle être sécurisée?

Une application sécurisée / sûre n'existe pas. La sécurité consiste à comprendre les risques, la probabilité et l'ampleur des pertes qu'elle peut causer et à identifier les éventualités et les stratégies d'atténuation pour maintenir une marge bénéficiaire saine. Les questions que vous devriez vous poser sont:

• que se passe-t-il lorsque la "détection de racine" échoue?
• contre quels types d'attaques la "détection de racine" est censée protéger?
• Quelle est la probabilité que cela se produise?
• Quels types de pertes un échec de "détection racine" peut-il causer?
• existe-t-il d'autres protections contre cela?
• Est-il possible de détecter rapidement ce type de violations?
• Est-il possible de déclencher des contingences qui réduisent ou éliminent les pertes?
• l'entreprise sera-t-elle toujours rentable avec ces pertes?

Toute logique importante doit être côté serveur

Vous semblez gêné par la possibilité de un attaquant pouvant installer votre application dans un environnement virtuel. Je soupçonne que bon nombre des contrôles de sécurité et des calculs importants sont du côté du client. Si tel est le cas, vous devez vraiment repenser votre application pour déplacer tous les contrôles côté serveur:

• Les API d'interface back-end exposées aux réseaux d'utilisateurs doivent nécessiter une authentification de l'utilisateur.

• Les API de l'interface back-end doivent limiter ce que l'utilisateur peut voir et faire. Les limites d'accès doivent être imposées par le côté serveur, jamais par le côté client. À l'exception, bien sûr, des services qui n'incluent pas d'informations et de commandes sensibles;

• Les API de l'interface back-end doivent tenir compte de la possibilité d'attaques par force brute. Un attaquant peut télécharger d'énormes portions de votre base de données et deviner des mots de passe et des codes de confirmation faibles en les essayant tous.

• Les API internes - celles utilisées par le back-end et non exposées aux réseaux d'utilisateurs - composent une couche de service interne qui devrait utiliser des utilisateurs de service ou des certificats clients pour l'authentification. Les informations de l ' utilisateur réel doivent être propagées à ces services à des fins de journalisation.

Je sais que c'est très décevant. Avec ces restrictions, les API de l'interface back-end doivent être très spécifiques aux flux de travail de l'application et donc moins réutilisable. Malheureusement, seules les API internes peuvent être réutilisables. Cela signifie également que les développeurs back-end devront très bien comprendre l'expérience utilisateur, les flux de travail conçus et travailler en étroite collaboration avec les équipes frontales, ce que la plupart des développeurs n'aiment pas ou sont prêts à faire.

Même avec toute la logique importante sur le serveur, il est nécessaire de concevoir les flux de travail pour tenir compte des autres risques

Si l'application suit les directives mentionnées ci-dessus, peu importe si le côté client l'application est falsifiée sur l'appareil d'un attaquant. Il ne pourra rien faire d'autre que ce que les informations d'identification de l'utilisateur dont il dispose lui permettraient de faire via l'application officielle côté client.

Mais si un appareil utilisateur réel est enraciné, les logiciels malveillants pourront:

• contourner la détection des appareils rootés;
• capturer les informations d'identification de l'utilisateur;
• rediriger l'utilisateur vers une fausse page;
• rediriger l'utilisateur vers une fausse application;
• contrôler à distance l'appareil;

Ces attaques ne sont pas très courantes. Ceux-ci sont difficiles car nécessitent généralement que l'utilisateur effectue des procédures compliquées. Mais si le produit est cher ou si les informations sont trop sensibles, ces attaques doivent être prises au sérieux.

Si votre inquiétude vient du fait que vos "vendeurs" traitent des produits coûteux dans lesquels les pertes sont importantes et difficiles à récupérer, vous devez tenir compte des barrières secondaires telles que:

• validation par le superviseur sur des opérations plus importantes;
• valider l'adresse de livraison avec plusieurs bases de données externes;
• améliorer le suivi des livraisons;
• imposer des contraintes de temps sur les livraisons en fonction du risque.

Si cela ne suffit toujours pas, vous pouvez choisir de fournir un appareil appartenant à l'entreprise qui est verrouillé pour empêcher installation de l'application et verrouillez la clé USB uniquement pour la charger. Je connais quelques personnes qui se promènent tout le temps avec trois téléphones d'entreprise de différentes entreprises: c'est toujours une chose.

Développer de bons logs et les surveiller

Le monitoring est aussi une bonne stratégie pour éviter de nombreuses pertes. Le retour en arrière des pertes sur les journaux permet de mieux comprendre comment elles se produisent et ce qui a échoué, de proposer des modifications aux produits ou du moins de surveiller ces situations pour obtenir des alertes précoces de situations similaires à l'avenir.

Si les journaux sont suffisamment détaillés, il existe des techniques de biométrie du comportement qui sont faciles à mettre en œuvre et peuvent détecter de nombreux types d'intrusions et certains types d'erreurs opérationnelles suffisamment tôt pour éviter les pertes.

Vous avez une version de bureau?

Quand vous avez dit "Nous avons une version mobile du produit", vous avez l'impression d'en avoir une autre. Avez-vous une version de bureau? Les systèmes d'exploitation de bureau sont enracinés par défaut et il n'y a pas d'isolation d'application. Si vous pouvez vivre avec une version de bureau, vous n'avez probablement même pas besoin de détection de racine en premier lieu.

C'est une bonne chose d'améliorer continuellement la sécurité, et vous devriez le faire, mais vous pouvez vous attendre à ce que la version mobile soit plus sûre que celle de bureau à moins que vous ne fassiez une horrible erreur dans le nouveau développement.