Mai 2018

Volume 33, numéro 5

Cet article a fait l'objet d'une traduction automatique.

Sécurité - Détecter les appareils Android rootés et s'y adapter à partir des applications Xamarin

Par Joe Sewell

Problème de novembre dernier, j’ai illustré comment vous pouvez utiliser le Runtime vérifie, une injection de code incluse avec Visual Studio 2017, dans la pour protéger vos applications .NET Framework à partir de toute utilisation non autorisée d’un débogueur, ainsi que contre la falsification (msdn.com/magazine / mt845626). Depuis, un nouveau type de vérification est devenu disponible. La vérification de la racine détecte quand une application Xamarin.Android s’exécute sur un appareil « rooté », qui permet aux applications ordinaires d’agir avec des autorisations d’administrateur (accès à la racine).

Dans cet article suivi, j’expliquer pourquoi rootés poser un risque que tous les développeurs Android doivent comprendre ; Décrit en détail comment les développeurs de Xamarin.Android peuvent utiliser le racine vérifie pour détecter et répondre à ce risque ; et meilleures pratiques avec un exemple de scénario.

Pourquoi vous avez besoin pour vous protéger contre la racine

La plateforme Xamarin vous permet de créer efficacement des applications mobiles pour les appareils Android, iOS et Windows. Les développeurs familiarisés avec les langages .NET tels que c# peuvent prendre ces connaissances et l’appliquer à l’espace mobile. Technologies, telles que Xamarin.Forms abstraite plusieurs font abstraction des différences entre les plateformes, ce qui réduit la complexité, de coût et les risques de développer des applications multiplateformes. En conservant vos outils Xamarin à jour, vous pouvez continuer à prendre en charge les nouvelles versions et les fonctionnalités de chaque plateforme.

Toutefois, certains aspects spécifiques à la plateforme de développement pour appareils mobiles méritent une attention particulière d’un développeur. Un aspect de ce type est la sécurité. Chaque plateforme a des risques de sécurité uniques et un modèle de sécurité unique pour gérer ces risques. Par exemple, les systèmes d’autorisation diffèrent entre les plateformes et parfois même entre les versions de la même plateforme.

Pour les applications Android, rootés sont un problème de sécurité particulièrement importante. Ces périphériques ont été modifiés pour autoriser les applications à sortir le sandbox de sécurité normale qui impose par le système d’exploitation. Cela peut exposer l’appareil à nombreux risques, tels que les logiciels malveillants et les enregistreurs de frappe vol de mot de passe. Souvent, les utilisateurs racine leurs appareils pour résoudre un problème, comme souhaitant une version d’une application qui n’est pas normalement disponible pour leur appareil, sans se rendre compte de la gravité de ces menaces. Dans d’autres cas, un utilisateur même peut-être pas conscient que l’appareil est rooté et par conséquent, vulnérable.

Dernière septembre, le Conseil de normes de sécurité de paiement carte Industry (PCI SSC) émis version 2.0 Mobile paiement acceptation consignes de sécurité pour les développeurs. Pour lutter contre les risques de sécurité associés aux périphériques associés à une racine, l’est recommandé des développeurs d’applications mobiles implémentent un mécanisme de réponse en quarantaine de l’application et de détection de la racine (bit.ly/2H5ymge). Voici le texte approprié à partir de la section 4.3 (accentuation ajoutée) :

[T] périphérique doit être analysé pour les activités anéantir controls—e.g de sécurité de système d’exploitation., jailbreaking ou racine, et, lors de la détection, l’appareil doit être mis en quarantaine par une solution qui le supprime à partir du réseau, supprime l’acceptation de paiement application de l’appareil, ou désactive la demande de paiement. Détection de rootés et racine hors connexion et de mise en quarantaine automatiquement sont essentiels, car des intrus peuvent tenter de mettre l’appareil dans un état hors connexion pour contourner encore plus la détection.

En plus des risques associés à un utilisateur légitime d’exploitation de l’application dans un environnement racine, un tel environnement peut également indiquer un utilisateur malveillant tente de rétroconcevoir l’application. Les pirates utilisent fréquemment des périphériques associés à une racine d’étudier et de créer des versions d’applications, afin de leur remplissage puis avec programme malveillant falsifiées. Le projet OWASP (ouvrir Web Application sécurité avoir) répertorie le code falsification comme l’un des risques Top 10 Mobile (bit.ly/2GNbd4o) et en particulier les appels effectués racine et réponse comme un moyen pour lutter contre ce risque. Ne pas le faire, en fonction d’OWASP avoir, peut entraîner des dommages réputation et les pertes de bénéfices.

Vérifications de la racine

Détection de périphériques associés à une racine peut être difficile. Un périphérique peut être associé à une racine à l’aide de différentes techniques et l’ensemble de techniques disponibles change au fil du temps et entre les versions d’Android. Par conséquent, le code de détection de racine doit constamment évoluent et adapter. Cela vient du fait que certaines techniques racine malveillants tentent de dissimuler leur utilisation, donc le code de détection du bon racine doit également traiter ces contre-mesures. Gestion d’un code de détection de racine à jour est difficile et ne peut pas être où vous souhaitez passer des ressources limitées.

Heureusement, vous n’avez pas à écrire votre propre code pour détecter la racine. Protection preEmptive - Dotfuscator Community Edition (CE), qui est inclus dans Visual Studio 2017, pour Windows, peut injecter des racine vérifie dans vos applications Xamarin.Android. Racine vérifie de détecter les environnements racine, même lorsque l’appareil est hors connexion. Outre une action standard « quitter l’application », vous pouvez configurer les contrôles pour répondre à la racine en appelant les codes d’application personnalisés.

Tout comme Xamarin, racine vérifie réduire la complexité, les coûts et les risques par rapport à la restauration de votre propre implémentation. Informez-vous Dotfuscator et qu’il traite la détection de la racine : retravailler sur des éléments de votre application plus rapide.

Exemple de scénario

Pour illustrer la racine vérifie, j’ai fourni un exemple d’application appelé TodoAzureAuth-protégé. Il est basé sur un exemple de Xamarin.Forms existant, TodoAzureAuth (bit.ly/2InvU48), à l’origine écrite par David Britch.

Le reste de cet article explique l’application, j’ai appliqué, ainsi que comment j’appliquer cette stratégie avec racine vérifie la stratégie de protection. Vous pouvez utiliser cette étude de cas, ainsi que des scénarios supplémentaires inclus dans le référentiel GitHub de l’exemple (bit.ly/2GQutOv), pour découvrir les approches de la racine vérifie que vous pouvez ensuite appliquer à vos propres applications Xamarin.Android.

Exemple : TodoAzureAuth d’origine se connecte à une instance de l’application Mobile Microsoft Azure, permettant aux utilisateurs d’afficher et modifier une liste de tâches partagée. Pour montrer comment effectuer une authentification dans une application Xamarin, l’exemple requiert que l’utilisateur pour vous connecter avec un compte Google avant d’accéder à la liste des tâches.

Démarrage de l’application sur la Page de connexion, qui ne contient aucun champ, juste un bouton de connexion. Lorsque l’utilisateur sélectionne ce bouton, l’application délègue le processus de connexion au système de Google OAuth, ce qui peut nécessiter l’utilisateur à entrer les informations d’identification, y compris un mot de passe. Par conséquent, l’application proprement dite ne gère pas les informations d’identification. Une fois que l’utilisateur est connecté, l’application affiche la Page de liste Todo, autoriser l’utilisateur à accéder à la liste des tâches partagée. L’utilisateur peut se déconnecter et revenir à la Page de connexion en sélectionnant le bouton de déconnexion.

Stratégie de protection : Pour cet article, j’ai traité le projet TodoAzureAuth Android, TodoAzure.Droid, comme s’il a été gestion des données sensibles, comme une application compatible PCI feriez. J’ai implémenté une stratégie de protection approprié d’injecter une vérification de la racine de l’application, à l’aide de Dotfuscator CE produisant une version protégée de l’application, Protected-TodoAzureAuth.

Dans l’application protégée, lorsque l’utilisateur sélectionne le bouton de connexion, la vérification de la racine Active. Si l’application s’exécute sur un appareil rooté, il s’arrête brusquement et toutes les autres tentatives pour exécuter l’application seront arrête également après un message d’erreur court, même si l’appareil n’est plus enraciné. Figure 1 montre une vue d’ensemble de l’application protégée par cette stratégie.

Figure 1 vue d’ensemble de l’exemple d’application TodoAzureAuth protégé

Cette stratégie s’aligne avec les recommandations formulées par les instructions PCI citées plus haut :

• L’application surveille le périphérique pour la racine.
• L’application met en quarantaine le périphérique en désactivant elle-même si racine est détecté.
• Ce contrôle de sécurité fonctionne même lorsque l’appareil est hors connexion.

Lorsque l’application elle-même, les alertes de message d’erreur désactive l’utilisateur que l’appareil est non sécurisé. N’est ne pas utilisé dans l’exemple, une application à l’aide de ce scénario pourrait également « téléphone accueil » pour une plateforme analytique telles que Visual Studio Application Center (bit.ly/2pYMuk5).

En plus de suivre les règles de PCI, cette stratégie également est alignée avec la recommandation OWASP avoir à arrêter l’application dans un environnement racine pour empêcher l’ingénierie à rebours. J’ai configuré la vérification de la racine pour activer à d’autres parties dans le code, et pas seulement le processus de connexion, pour que si une personne malveillante génère une version falsifiée de l’application avec la détection de racine du processus de connexion supprimée, les autres parties de l’application puissent toujours réagir à la racine. Dotfuscator obfusqué également le code, l’ajout d’une autre couche de protection à l’application et la vérification de la racine.

Pas toutes les applications ont les mêmes exigences de sécurité, et par conséquent pas toutes les applications doivent réagir à la racine de la même façon. Vous avez choisi une approche stricte de l’exemple, mais une stratégie plus modérée pourrait permettre l’application à exécuter sur les périphériques associés à une racine dans certaines circonstances. Pour obtenir un exemple, consultez « Une stratégie de Protection autre. »

Protégé par exemple : Vous pouvez consulter l’exemple Protected-TodoAzureAuth en utilisant le lien GitHub fourni précédemment. Sur la branche maître par défaut, j’ai déjà configuré Dotfuscator CE pour protéger TodoAzure.Droid avec une vérification de la racine, afin que l’application répond à la stratégie expliquée plus haut. Vous pouvez suivre l’historique Git, en commençant par la branche avant de contrôles, voir comment puis-je appliquées les étapes décrites dans cet article à l’exemple.

Consultez le fichier Lisezmoi de l’exemple pour plus d’informations sur la façon de configurer, générer et exécuter l’exemple. Le fichier Lisez-moi contient également des détails sur les autres branches présents dans le référentiel qui illustrent des stratégies de protection différent de celui utilisé pour cet article, telles que la stratégie décrite dans « Une stratégie de Protection autre. »

L’intégration de Dotfuscator dans Xamarin Builds

Dotfuscator fonctionnant sur des assemblys .NET (fichiers .dll et .exe), les formats de plateforme mobile pas tels que les Packages Android (fichiers .apk), j’ai dû intégrer Dotfuscator dans le processus de génération de Xamarin. Configurer l’intégration requiert l’installation et l’inscription de Dotfuscator CE, téléchargement d’un fichier de cibles de MSBuild spécialisé et modifiant le fichier projet pour inclure ces cibles. J’ai écrit sur la façon d’effectuer ces étapes d’intégration pour le Blog de Xamarin, par conséquent, consultez les instructions de la section bit.ly/2w9em6c.

Remarque importante : Vérifications de la racine d’exiger Dotfuscator CE 5,35 ou version ultérieure pour Visual Studio 2017. Vous pouvez toujours obtenir la dernière version à bit.ly/2fuUeow.

Avoir suivi les instructions de Xamarin Blog pour protéger version du fichier projet TodoAzure.Droid | Configuration de build AnyCPU. Cet article ne concerne que ce projet Android, car les vérifications de racine sont une fonctionnalité Android spécifiques, mais vous pouvez également suivre les instructions de Xamarin Blog pour protéger les e/s et les projets de plateforme Windows universelle (UWP) avec obscurcissement de code.

Configurer la Protection de Dotfuscator

Une fois que j’ai intégré Dotfuscator dans le processus de génération du projet TodoAzure.Droid, j’ai configuré la protection via l’interface utilisateur de Dotfuscator CE. Les paramètres de protection pour un projet sont enregistrés dans un fichier de configuration de Dotfuscator spécialisé, qui ajoute de l’intégration de build à votre projet la première fois qu’il génère.

Création du fichier de configuration de Dotfuscator : À l’aide de Visual Studio 2017, créé le TodoAzure.Droid configuration pour la plateforme AnyCPU, qui est la configuration que j’avais configurés pour utiliser Dotfuscator de build de projet dans la version. Cela produit un nouveau Dotfuscator fichier de configuration, DotfuscatorConfig.xml, dans le répertoire du projet. J’ai ajouté ce nouveau fichier au contrôle de code source, donc je pourrais ultérieurement personnaliser, réappliquez la protection basée sur la personnalisation.

La build a également créé un répertoire DotfuscatorReports dans mon répertoire du projet, c'est-à-dire où Dotfuscator écrit les différents fichiers de rapport lorsqu’il s’exécute dans le cadre de l’intégration. Étant donné que le contenu de ce répertoire mettre à jour chaque build, j’avais mon contrôle de code source à ignorer ce répertoire.

Dotfuscator d’ouverture : Pour personnaliser le fichier de configuration de Dotfuscator, ouvert l’interface utilisateur de Dotfuscator CE à partir de Visual Studio 2017 en sélectionnant Outils | Protection de preEmptive : Dotfuscator. Dans la UI Dotfuscator survenus, j’ai choisi fichier | Ouvrez le projet, accédé au répertoire du projet TodoAzure.Droid et sélectionné DotfuscatorConfig.xml, le fichier de configuration de Dotfuscator. L’UI Dotfuscator mis à jour pour afficher les deux assemblys de que ce fichier de configuration de Dotfuscator protège : TodoAzure.Droid.dll lui-même et l’assembly de bibliothèque (PCL) de classes portable TodoAzure.dll.

Gardez à l’esprit que l’option de générer le projet dans l’UI Dotfuscator n’effectue pas étapes d’empaquetage de Xamarin. Pour garantir que le Package Android contient les assemblys protégés, générez le projet dans Visual Studio ou MSBuild à la place.

Activation de l’Injection de Code : Vérifications font partie des fonctionnalités d’injection de code de Dotfuscator. Pour activer l’injection de code, je clic droit sur le nœud de l’injection de code dans la barre de navigation de Dotfuscator et activé l’option Enable. Couleur du texte du nœud d’Injection modifié de gris en noir, indiquant que l’injection de code a été activée.

Affichage configuré vérifications : La page de Dotfuscator vérifie affiche une liste de toutes les vérifications de configuration pour un fichier de configuration chargé dans ce cas DotfuscatorConfig.xml dans le projet TodoAzure.Droid. Pour afficher cette page, j’ai sélectionné le nœud de l’injection de code et a basculé vers l’onglet de contrôle.

Lorsque je visité tout d’abord cette liste, il était vide. Une fois que j’ai configuré une nouvelle racine de la vérification, comme j’expliquer dans la section suivante, la liste mise à jour pour inclure une ligne pour cette vérification, comme dans Figure 2. Je pourrais permet d’afficher la configuration de la vérification d’en double-cliquant sur cette ligne.

Figure 2 Dotfuscator vérifie la Page, affichant une vérification de la racine

Notez que vous pouvez configurer plusieurs racine recherchez un seul fichier de configuration de Dotfuscator, bien que je n’a pas le faire pour cet article. Pour obtenir un exemple d’une application protégée par plusieurs vérifications, consultez l’application AdventureWorksSalesClient .NET Framework que j’ai écrit sur la dernière novembre.

Ajout d’une vérification de la racine

Dans la page des vérifications, j’ai ajouté une racine de la vérification en cliquant sur le bouton Ajouter une vérification de racine. Lorsque je l’ai fait, Dotfuscator affiche une nouvelle fenêtre pour la configuration de la nouvelle vérification. Figure 3 montre la configuration terminée ; cette section explique la signification de chaque paramètre et la raison pour laquelle j’ai choisi ces paramètres.

Configuration de la figure 3 de la vérification de la racine, des emplacements supplémentaires masqués par le nœud TodoAzure.dll réduit

Emplacements : Chaque contrôle est associé à une ou plusieurs méthodes dans l’application, appelés emplacements. Lorsque l’application appelle une telle méthode, la vérification de la racine Active, en détectant à ce moment si l’appareil semble être associé à. Après que l’exécution de tous les configuré des fonctionnalités de création de rapports et de réponse, en supposant que de ces mesures n’a pas quitter l’application, le contrôle retourne le contrôle vers le haut de la méthode.

Pour contrôle de ce scénario, j’ai sélectionné plusieurs emplacements. L’emplacement utilisé tout d’abord dans l’application est TodoAzure.Droid.MainActivity.AuthenticateAsync, qui coordonne une demande de connexion. À l’aide de cet emplacement signifie que la vérification de la racine effectue sa détection et réponse à chaque fois que le processus de connexion commence.

Par la stratégie de protection, une application en cours d’exécution sur un appareil rooté se ferme lorsqu’il atteint tout d’abord la méthode AuthenticateAsync. Par conséquent, pourquoi ajouter autres méthodes qui se produisent ultérieurement dans le cycle de vie de l’application en tant qu’emplacements supplémentaires ? Il s’agit de protéger l’application contre l’ingénierie à rebours. Si une personne malveillante crée une version falsifiée de l’application qui ignore ou supprime le code de vérification de la racine au AuthenticateAsync, ces autres emplacements serez toujours en mesure de réagir à un environnement racine.

Certains de ces emplacements supplémentaires sont définis dans TodoAzure.dll. Cela peut être surprenant, car cet assembly contient la logique commune à toutes les plateformes de Xamarin, pas simplement Android. Comment peut Dotfuscator injecter une vérification de la racine, qui détecte les appareils Android associé à une racine, dans un assembly de plateforme agnostique ? Rappelez-vous que ce fichier de configuration de Dotfuscator est spécifique au projet TodoAzure.Droid, qui fait référence au projet TodoAzure. Lorsque Dotfuscator modifie TodoAzure.dll, elle va modifier uniquement l’assembly que Visual Studio ou des copies de MSBuild pour les utilisent dans le projet actuel, TodoAzure.Droid. Assembly du projet TodoAzure d’origine reste inchangé.

Notification d’application : Contrôles peuvent signaler les résultats de leur détection de code d’application. Ainsi, vous avez personnalisé les comportements de création de rapports et de réponse, tout en ayant les vérifications injectant par handle de Dotfuscator le travail de détection. Le code d’application qui reçoit le résultat de la détection est appelé un récepteur de Notification d’Application.

Pour répondre à la stratégie de protection dans ce scénario, nécessaires pour que l’application elle-même, désactiver pour les exécutions futures de l’application se termine avec un message d’erreur. J’ai choisi d’ajouter la désactivation de la logique dans une méthode, TodoAzure.App.DisableIfCompromised et l’utiliser comme récepteur de la vérification en définissant les propriétés de vérification suivantes :

• ApplicationNotificationSinkElement: Le type d’élément de code ; Dans ce cas, une méthode.
• ApplicationNotificationSinkName: Le nom simple de l’élément de code ; Dans ce cas, DisableIfCompromised.
• ApplicationNotificationSinkOwner: Le type qui contient l’élément de code ; Dans ce cas, TodoAzure.App.

Les emplacements de la vérification peuvent appeler cette méthode de récepteur comme il est public et static. Pour être compatible avec une vérification, la méthode est synchrone (non-async), prend un argument unique de type bool et possède un type de retour void.

Une fois activé, le contrôle appelle la méthode, en passant la valeur true argument si l’appareil est rooté et false dans le cas contraire. Lorsque cet argument a la valeur true, autrement dit, lorsque la vérification détecte racine, la méthode enregistre une valeur dans un stockage local, qui indique l’application est maintenant désactivée. Une propriété qui l’accompagne, IsDisabled, expose la valeur enregistrée :

// Definitions in TodoAzure.App
private const string DisabledPropertyKey = "AppStatus";
public static void DisableIfCompromised(bool wasCompromised)
{
  if (!wasCompromised) { return; }
  Current.Properties[DisabledPropertyKey] = new Random().Next();
  SavePropertiesNow();
}
public static bool IsDisabled =>
  Current.Properties.ContainsKey(DisabledPropertyKey);

Une fois que l’application est désactivée, les exécutions futures doivent afficher un message d’erreur et de sortie. Pour ce faire, je se TodoAzure.LoginPage.OnAppearing, qui est appelée juste avant que la Page de connexion s’affiche au démarrage de l’application. Si l’application est désactivée, cette méthode masque la Page de connexion, affiche une boîte de dialogue d’erreur et se termine.

// Definition in TodoAzure.LoginPage
protected override async void OnAppearing()
{
  if (App.IsDisabled)
  {
    IsVisible = false;
    var message = "The security of this device has been compromised. "
      + " The app will exit.";
    await DisplayAlert("App deactivated", message, "Exit App");
    App.Exit(); // Delegates to platform-specific exit logic
  }
  base.OnAppearing();
}

Étant donné que vous souhaitez également vous défendre contre l’ingénierie à rebours, j’ai pris des mesures supplémentaires pour garantir que l’application serait plus résistante face à une telle attaque. J’ai utilisé un nom vague pour la valeur enregistrée, AppStatus et que vous définissez la valeur en un nombre aléatoire, qui masque la signification de la valeur. J’ai configuré également Dotfuscator pour brouiller l’application, renommer les identificateurs comme DisableIfCompromised, pour un attaquant d’afficher le code décompilé ne peut pas identifier facilement cette méthode comme étant dignes d’intérêt. Pour plus d’informations sur la façon dont j’ai configuré obscurcissement de changement de nom, consultez le fichier Lisezmoi de l’exemple.

Action : Alors que le récepteur (méthode DisableIfCompromised) définit une propriété pour vous assurer de futures exécutions de la sortie de l’application, il ne quitter l’application lors de la racine est détecté en premier. Au lieu de cela, j’ai configuré le contrôle pour effectuer automatiquement cette opération en définissant la propriété de vérification d’Action pour quitter.

Lorsque la vérification détecte un appareil rooté, il notifie le récepteur et puis quitte immédiatement l’application. En ayant la vérification, plutôt que le récepteur, effectuez cette sortie initiale, j’ai répartir plusieurs copies de la logique de sortie dans l’application. Comme avec plusieurs emplacements, plusieurs copies de la logique de sortie permettent à l’application pour mieux vous protéger lorsqu’une personne malveillante a supprimé certaines de la racine de chèques.

Générer et tester l’application

Après avoir configuré la vérification de la racine, j’ai quitté une fenêtre de la vérification d’en sélectionnant OK, puis que vous avez enregistré mes modifications au fichier de configuration Dotfuscator en cliquant sur fichier | Enregistrez le projet. J’ai créé TodoAzure.Droid dans Visual Studio pour tester l’application protégée, afin de vérifier que j’ai configuré correctement la vérification de racine afin d’appliquer la stratégie de protection souhaité.

J’ai testé l’application sur un appareil non racine, sur un appareil rooté et sur un émulateur. Sur l’appareil non racine, l’application a fonctionné normalement, ce qui me permet de vous connecter pour afficher la liste des tâches. Toutefois, sur le périphérique racine et sur l’émulateur, après avoir sélectionné le bouton de connexion, l’application fermée brusquement. Après le lancement de nouveau l’application, l’application affiche la boîte de dialogue Erreur dans Figure 4; une fois que j’ai fermé la boîte de dialogue, l’application s’est arrêtée une fois de plus. Pour afficher la Page de connexion à nouveau, j’ai dû désinstallez, puis réinstallez l’application.

Figure 4 le TodoAzure.Droid protégée en cours d’exécution dans un émulateur

Pour résumer

J’espère que cet article a aidé à éclairer un moyen de détecter efficacement et répondre à la racine des appareils Android à l’aide des outils libre inclus dans Visual Studio. Alors que j’ai utilisé une application exemple bien connu en tant que référence, vous pouvez appliquer les idées présentées dans cet article pour toutes sortes d’applications de Xamarin.Android et diverses autres stratégies de protection.

Si vous souhaitez en savoir plus sur les vérifications, je vous recommande de lire mon précédent article MSDN Magazine. Ce dernier, j’ai abordé des types de contrôles que vous pouvez appliquer à des applications .NET Framework et comment l’utilisation de contrôles pouvez empêcher les violations de données.

Vous pouvez également être intéressé par les fonctionnalités avancées de vérification et de brouillage de Dotfuscator Professional Edition (bit.ly/2xgEZcs) ou l’outil d’accompagnement pour Java et les applications Android traditionnelles, Protection PreEmptive - DashO (bit.ly/2ffHTrN). Vous pouvez conserver à jour avec l’évolution toutes les vérifications et Protection préemptive en suivant PreEmptive Solutions sur Twitter (twitter.com/preemptive) et en consultant notre blog (preemptive.com/blog).

Une stratégie de Protection secondaire

Cet article présente une stratégie pour la détection et la réaction à rootés, mais les autres stratégies sont également possibles. La stratégie que vous choisissez doit être adaptée à votre application, le contexte dans lequel votre application est utilisée et la sécurité des risques vous souhaitez adresse. Vous pouvez ensuite appliquer racine vérifie pour implémenter la stratégie choisie. Par exemple, si votre application ne doit pas quitter les circonstances, vous pouvez configurer une vérification de racine pour désactiver certaines fonctionnalités lors de la racine est détectée, plutôt que d’en quittant l’application.

Une seule application même devra peut-être réagir à la racine de différentes façons, selon les informations connues au moment de l’exécution. Considérez une application disponible dans plusieurs régions géographiques. Réponse de l’application à la racine deviez varient selon la région pour se conformer aux lois et réglementations, surtout si la réponse inclut l’envoi des rapports d’incidents au développeur (« accueil appelant »).

Lorsque vous développez une stratégie de protection, vous devez également prendre en compte l’impact de votre stratégie sur les utilisateurs de votre application qui ont enracinée intentionnellement leurs appareils en toute bonne foi. Ces utilisateurs « power » peuvent être une partie importante de votre base de clients, et en interdisant rootés Impossible de lecteur leur en s’éloignant de votre application. Vous devez évaluer les risques de sécurité associés aux périphériques racine contre les risques liés aux faisant fuir aux utilisateurs légitimes de ces appareils.

Cet article, je suppose que TodoAzure.Droid gérée des données sensibles, et par conséquent, pour empêcher le vol de données et d’ingénierie à rebours, rootés doivent être totalement interdites. Si j’avais traité à la place les données comme non sensibles, je pourrais ont implémenté une stratégie de protection qui permet aux périphériques racine dans certaines circonstances, rendant l’application plus accessible aux utilisateurs avec pouvoir. Dans cette stratégie de remplacement, au lieu de l’application elle-même, la désactivation de l’application avertit l’utilisateur lors de la détection d’un appareil rooté. Cet avertissement garantit que l’utilisateur est informé de l’état non sécurisé de l’appareil et les risques associés tels que le vol d’informations d’identification. L’utilisateur peut choisir d’annuler la tentative de connexion ou accepter les risques et poursuivre la connexion.

Sur la branche avertir les utilisateurs du référentiel GitHub de Protected-TodoAzureAuth, j’ai configuré Dotfuscator CE pour protéger TodoAzure.Droid avec une vérification de la racine qui implémente cette stratégie de protection autre. Le fichier Lisez-moi sur cette branche explique les points plus précis de la configuration.

Notez que cette stratégie de remplacement permet un compromis entre l’accessibilité aux utilisateurs avec pouvoir et les menaces d’ingénierie à rebours. Sous cette stratégie, les mauvais acteurs peuvent toujours installer l’application sur un appareil rooté dans le cadre de l’ingénierie à rebours ; la boîte de dialogue d’avertissement ne les arrêter. J’ai utilisé toujours Dotfuscator à obscurcir l’application, en fournissant un degré de protection contre l’ingénierie à rebours. Dans une application réelle peut implémenter des contrôles supplémentaires, par exemple, exigez l’authentification spéciale pour utiliser l’application sur un appareil rooté.

Figure A affiche l’avertissement affiché par l’application sur un appareil rooté.

Figure un TodoAzure.Droid protégé par cette stratégie de remplacement, en cours d’exécution dans un émulateur, une fois que l’utilisateur sélectionne le bouton de connexion

Joe Sewellest un ingénieur logiciel et rédacteur technique de l’équipe de Dotfuscator de PreEmptive Solutions. Il a précédemment écrit pour MSDN Magazine et Blog officiel de Xamarin.

Merci à l'expert technique Microsoft suivant d'avoir relu cet article : David Britch
David Britch fonctionne dans le groupe de documentation de Xamarin chez Microsoft. Il a écrit pour une plage de publications de développement de logiciels, y compris la documentation, documentation relative au Guide, implémentations de référence, des livres blancs, vidéos et formations instructeurs