Artículo
06/14/2018

Mayo de 2018

Volumen 33, número 5

Seguridad: Detectar y responder a dispositivos Android modificados desde Xamarin Apps

En el número del último noviembre, muestra cómo se puede utilizar en tiempo de ejecución comprueba, una inserción de código característica que se incluye con Visual 2017 Studio, para proteger las aplicaciones de .NET Framework de uso no autorizado de un depurador, así como contra la manipulación (msdn.com/magazine / mt845626). Desde entonces, haya disponible un nuevo tipo de comprobación. La comprobación de raíz detecta cuando se ejecuta una aplicación Xamarin.Android en un dispositivo "raíz", que permite que aplicaciones normales para que actúe con permisos de administrador (acceso a la raíz).

En este artículo de seguimiento, explicar por qué dispositivos suponen un riesgo de que todos los desarrolladores de Android deben entender; detalla cómo Xamarin.Android a los desarrolladores pueden usar la raíz se comprueba para detectar y responder a este riesgo; y demostrar los procedimientos recomendados con un escenario de ejemplo.

¿Por qué necesita para protegerse frente a la raíz

La plataforma Xamarin permite crear eficazmente aplicaciones móviles para dispositivos Windows, iOS y Android. Los programadores familiarizados con lenguajes .NET como C# pueden tomar ese conocimiento y aplicarla al espacio de dispositivos móvil. Tecnologías como Xamarin.Forms abstraen alejadas muchas de las diferencias entre plataformas, lo que reduce la complejidad, costo y riesgo de desarrollar aplicaciones multiplataforma. Por mantener actualizadas las herramientas de Xamarin, puede continuar admitir las nuevas versiones y características de cada plataforma.

Sin embargo, algunos aspectos específicos de la plataforma de desarrollo de aplicaciones móvil merecen atención de un desarrollador. Un aspecto de este tipo es la seguridad. Cada plataforma tiene riesgos de seguridad únicos y un modelo de seguridad único para tratar estos riesgos. Por ejemplo, los sistemas de permiso difieren entre varias plataformas y a veces incluso entre versiones de la misma plataforma.

Para las aplicaciones Android, dispositivos son un problema de seguridad especialmente importante. Estos dispositivos se han modificado para permitir que las aplicaciones interrumpir el espacio aislado de seguridad normal que impone el sistema operativo. Esto puede exponer el dispositivo para muchos peligros, como el malware y los registradores de pulsaciones de robo de contraseña. A menudo, los usuarios raíz sus dispositivos para resolver algún problema, como que una versión de una aplicación que no está disponible normalmente para su dispositivo, sin ser consciente de la gravedad de estas amenazas. En otros casos, un usuario no puede ser incluso tenga en cuenta que el dispositivo se ha modificado y, por tanto, vulnerable.

Último mes de septiembre, el Consejo de estándares de seguridad de pago tarjeta Industry (PCI SSC) había emitido versión 2.0 de las directrices de seguridad móvil aceptación de pago para los desarrolladores. Para luchar contra los riesgos de seguridad asociados a dispositivos, las directrices recomiendan a los desarrolladores de aplicaciones móviles implementan la detección de raíz y un mecanismo de respuesta para la aplicación en cuarentena (bit.ly/2H5ymge). Este es el texto correspondiente de la sección 4.3 (énfasis agregado):

[T] dispositivo se debe supervisar para las actividades que anular controls—e.g. de seguridad de sistema operativo, jailbreaking o la raíz, y, cuando detecta, el dispositivo debe ser puestos en cuarentena por una solución que se quita de la red, evita la aceptación de pago aplicación del dispositivo, o deshabilita la solicitud de pago. Detección de jailbreak y raíz sin conexión y auto-quarantine son factores clave puesto que algunos los atacantes pueden tratar de poner el dispositivo en un estado sin conexión para eludir aún más la detección.

Además de los riesgos asociados con un usuario legítimo que funciona la aplicación en un entorno de raíz, un entorno de este tipo también puede indicar un usuario malintencionado intenta la aplicación de ingeniería inversa. Con frecuencia, los atacantes usan dispositivos para estudiar y crear alteradas versiones de aplicaciones, lo, a continuación, rellenan con malware que. El proyecto de seguridad del aplicación Web (OWASP) abierto enumera el código de manipulación como uno de los riesgos de Top 10 Mobile (bit.ly/2GNbd4o) y específicamente llamadas raíz detección y respuesta como una forma de combatir este riesgo. No hace esto, según OWASP, puede provocar daños la reputación y la pérdida de beneficios.

Comprobaciones de raíz

Detectar dispositivos puede resultar complicado. Un dispositivo se puede originar muchas técnicas diferentes, y el conjunto de técnicas disponibles cambia con el tiempo y entre versiones de Android. Como resultado, el código de detección de raíz debe evolucionar constantemente y adaptar. Esto se produce por el hecho de que algunas técnicas de raíz malintencionados intentan ocultar su uso, por lo que el código de detección de buena raíz también debe solucionar estas contramedidas. El mantenimiento del código de detección de raíz actualizado es difícil y no puede ser donde desea gastar los recursos limitados.

Por suerte, no tienes que escribir su propio código para detectar la raíz. Protección de preEmptive: Dotfuscator Community Edition (CE), que se incluye con Visual Studio de 2017 para Windows, puede insertar raíz comprueba en las aplicaciones de Xamarin.Android. Raíz comprueba detectar la raíz de los entornos, incluso cuando el dispositivo está desconectado. Además de una acción de "salir de la aplicación" estándar, puede configurar las comprobaciones para responder a la raíz de un elemento mediante una llamada a personalizar el código de la aplicación.

Igual que Xamarin, raíz comprueba reducir la complejidad, el costo y el riesgo en comparación con las sucesivas su propia implementación. Manténgase al día Dotfuscator y permiten controlar la detección de raíz: volver a trabajar en las partes interesantes de la aplicación más rápida.

Escenario de ejemplo

Para mostrar raíz comprueba, he proporcionado una aplicación de ejemplo denominada TodoAzureAuth protegidos. Se basa en un ejemplo de Xamarin.Forms existente, TodoAzureAuth (bit.ly/2InvU48), David Britch originalmente haya escrito.

El resto de este artículo explica la aplicación, la estrategia de protección aplica a él, y cómo aplica dicha estrategia con comprobaciones de raíz. Puede usar este caso práctico, así como los escenarios adicionales incluidos en el repositorio de GitHub del ejemplo (bit.ly/2GQutOv), para obtener información sobre métodos para raíz comprueba, a continuación, puede aplicar a sus propias aplicaciones Xamarin.Android.

Ejemplo: TodoAzureAuth original se conecta a una instancia de la aplicación móvil de Microsoft Azure, permitiendo a los usuarios ver y modificar una lista de tareas compartida. Para demostrar cómo realizar la autenticación en una aplicación de Xamarin, el ejemplo requiere que el usuario iniciar sesión con una cuenta de Google antes de acceder a la lista de tareas.

En la página de inicio de sesión, que no tiene ningún campo, un botón de inicio de sesión se inicia la aplicación. Cuando el usuario selecciona este botón, la aplicación delega el proceso de inicio de sesión al sistema de OAuth de Google, lo que puede requerir al usuario que escriba las credenciales, incluida una contraseña. Como resultado, la propia aplicación no controla las credenciales. Una vez que el usuario ha iniciado sesión, la aplicación muestra la página de lista de tareas, lo que permite al usuario acceder a la lista de tareas compartida. El usuario puede cerrar la sesión y volver a la página de inicio de sesión, seleccione el botón de cierre de sesión.

Estrategia de protección: Para este artículo, trata el proyecto de TodoAzureAuth Android, TodoAzure.Droid, como si se control de datos confidenciales, como haría con una aplicación compatible con PCI. Implementa una estrategia de protección adecuado mediante Dotfuscator CE para insertar una raíz de comprobación en la aplicación, que produce una versión protegida de la aplicación, TodoAzureAuth protegidos.

En la aplicación protegida, la comprobación de raíz activa cuando el usuario selecciona el botón de inicio de sesión. Si la aplicación se ejecuta en un dispositivo raíz, este se cierra abruptamente y todos los intentos adicionales para ejecutar la aplicación también se cerrará después de un mensaje breve del error, incluso si el dispositivo ya no se ha modificado. Figura 1 muestra un resumen de la aplicación protegida por esta estrategia.

Figura 1 Introducción de la aplicación de ejemplo TodoAzureAuth protegido

Esta estrategia se alinea con las recomendaciones realizadas por las instrucciones PCI entrecomilladas anteriormente:

La aplicación supervisa el dispositivo para la raíz.
La aplicación se pone en cuarentena el dispositivo propio deshabilitando si se detecta la raíz de un elemento.
Este control de seguridad funciona incluso cuando el dispositivo está desconectado.

Cuando la aplicación deshabilita, las alertas de mensaje de error al usuario que el dispositivo no es seguro. Aunque no se usan en el ejemplo, una aplicación con este escenario podría también "llamar a casa" para una plataforma de análisis como centro de aplicación de Visual Studio (bit.ly/2pYMuk5).

Además de seguir las directrices PCI, esta estrategia también se alinee con la recomendación OWASP para cerrar la aplicación en un entorno de raíz para evitar la ingeniería inversa. He configurado la comprobación de raíz para activar en otras partes en el código, no solo el proceso de inicio de sesión, para que si un atacante genera una versión modificada de la aplicación con la detección de raíz del proceso de inicio de sesión quitada, otras partes de la aplicación todavía puedan reaccionar a raíz de un elemento. Dotfuscator había ofuscado también el código, agrega otra capa de protección para la aplicación y la comprobación de la raíz.

No todas las aplicaciones tienen los mismos requisitos de seguridad y, por tanto, no todas las aplicaciones deben reaccionar a la raíz de la misma manera. Se ha elegido un enfoque estricto para el ejemplo, pero una estrategia más flexible podría permitir la aplicación se ejecute en dispositivos en determinadas circunstancias. Para obtener un ejemplo, vea "Una estrategia de protección alternativo".

Ejemplo protegido: Puede ver el ejemplo de TodoAzureAuth protegidos mediante el vínculo de GitHub proporcionado anteriormente. En la bifurcación principal de manera predeterminada, ya he he configurado Dotfuscator CE para proteger TodoAzure.Droid con una comprobación de la raíz de forma que la aplicación cumpla la estrategia que se ha explicado anteriormente. Puede seguir el historial de Git, a partir de la bifurcación antes de comprobaciones, para ver cómo aplican los pasos de este artículo para el ejemplo.

Vea el archivo Léame del ejemplo para obtener más información acerca de cómo configurar, compilar y ejecutar el ejemplo. El archivo Léame también incluye detalles en otras bifurcaciones presentes en el repositorio que muestran las estrategias de protección diferente que el utilizado para este artículo, por ejemplo, la estrategia que se detallan en "Una estrategia de protección alternativo".

Compilaciones de integración Dotfuscator en Xamarin

Dado que Dotfuscator funciona en ensamblados .NET (archivos .dll y .exe), plataforma móvil no formatos, como paquetes de Android (.apk archivos), lo que tuve que integrar Dotfuscator en el proceso de compilación de Xamarin. La configuración de la integración requiere instalar y registrar Dotfuscator CE, descargar un archivo de destinos de MSBuild especializado y modificar el archivo de proyecto para incluir esos destinos. He escrito sobre cómo realizar estos pasos de integración del Blog de Xamarin, por lo tanto, consulte las instrucciones en bit.ly/2w9em6c.

Nota importante: Raíz comprueba requieren Dotfuscator CE versión 5,35 o posterior para Visual Studio de 2017. Siempre puede obtener la versión más reciente en bit.ly/2fuUeow.

He seguido las instrucciones de Xamarin Blog para proteger la versión del archivo de proyecto TodoAzure.Droid | Configuración de compilación AnyCPU. En este artículo solo tiene que ver con este proyecto Android porque las comprobaciones de raíz son una característica específica de Android, pero también puede seguir las instrucciones de Xamarin Blog para proteger iOS y proyectos de plataforma Universal de Windows (UWP) con la ocultación de código.

Configurar la protección de Dotfuscator

Una vez que integra Dotfuscator en proceso de compilación del proyecto TodoAzure.Droid, he configurado la protección a través de la interfaz de usuario de Dotfuscator CE. La configuración de protección de un proyecto se guarda en un archivo de configuración de Dotfuscator especializado, que la integración de compilación que se agrega al proyecto la primera vez que se genera.

Crear el archivo de configuración de Dotfuscator: Con Visual Studio de 2017, he creado la configuración para la plataforma AnyCPU, que es la configuración que había configurado para usar Dotfuscator de compilación del proyecto en la versión de TodoAzure.Droid. Esto genera un nuevo Dotfuscator archivo de configuración, DotfuscatorConfig.xml, en el directorio del proyecto. Este nuevo archivo agrega al control de código fuente por lo más adelante podría personalizar y volver a aplicar la protección en función de que la personalización.

La compilación también crea un directorio DotfuscatorReports en el directorio del proyecto, que es donde escribe Dotfuscator los diversos archivos de informe cuando se ejecuta como parte de la integración. Debido a contenido de este directorio actualiza cada compilación, tuve mi control de código fuente pasar por alto este directorio.

Dotfuscator de apertura: Para personalizar el archivo de configuración de Dotfuscator, abre la interfaz de usuario de Dotfuscator CE desde Visual Studio de 2017 eligiendo herramientas | Protección de preEmptive: Dotfuscator. En la UI de Dotfuscator que aparecían, que deseaba archivo | Abra el proyecto, navega hasta el directorio del proyecto TodoAzure.Droid y selecciona DotfuscatorConfig.xml, el archivo de configuración de Dotfuscator. La UI Dotfuscator se actualiza para mostrar los dos ensamblados que protege el archivo de configuración de Dotfuscator: TodoAzure.Droid.dll propio y el ensamblado de biblioteca (PCL) de clases portable TodoAzure.dll.

Tenga en cuenta que la opción de compilar el proyecto en la UI de Dotfuscator no realice los pasos de empaquetado de Xamarin. Para asegurarse de que el paquete de Android contiene los ensamblados protegidos, compile el proyecto de Visual Studio o MSBuild en su lugar.

Habilitar la inserción de código: Comprobaciones forman parte de las características de inyección de código de Dotfuscator. Para habilitar la inserción de código, he con el botón secundario del nodo de inyección de código en la barra de navegación de Dotfuscator y activa la opción Enable. Color del texto del nodo de inyección de código cambiado de color gris a negro, que indica que se habilitó la inyección de código.

Ver configurado comprobaciones: La página Dotfuscator comprobaciones muestra una lista de todas las comprobaciones configuradas para un archivo de configuración cargado, en este caso DotfuscatorConfig.xml en el proyecto TodoAzure.Droid. Para ver esta página, selecciona el nodo de inyección de código y cambia a la ficha comprobaciones.

Cuando visita por primera vez esta lista, estaba vacío. Una vez que configura una nueva raíz de comprobación, tal y como explica en la sección siguiente, la lista se actualiza para incluir una fila para comprobación, tal como se muestra en figura 2. La configuración de la comprobación podría ver haciendo doble clic en esa fila.

El Dotfuscator comprueba la página, que muestra una comprobación de raíz
Figura 2 la Dotfuscator comprueba la página, que muestra una comprobación de raíz

Tenga en cuenta que puede configurar más de una raíz busque un archivo de configuración de Dotfuscator único, aunque no hacerlo para este artículo. Para obtener un ejemplo de una aplicación protegida por varias comprobaciones, vea la aplicación de .NET Framework de AdventureWorksSalesClient que he escrito sobre noviembre últimos.

Agregar una comprobación de raíz

En la página comprobaciones, agregué una raíz de comprobación haciendo clic en el botón Agregar comprobación de raíz. Cuando hizo, Dotfuscator muestra una nueva ventana para configurar la comprobación de nuevo. Figura 3 muestra la configuración finalizada; esta sección explica el significado de cada valor y por qué eligió esos valores.

Figura 3 configuración de la comprobación de la raíz: ubicaciones adicionales ocultos por un nodo TodoAzure.dll contraído

Ubicaciones: Cada comprobación que está asociado a uno o varios métodos en la aplicación, llamado a ubicaciones. Cuando la aplicación llama a un método de este tipo, la comprobación de raíz se activa, detectar en ese momento, si el dispositivo parece ser la ruta raíz. Después de ejecutar todos configurado la funcionalidad de informes y respuesta, suponiendo que dichas medidas no salir de la aplicación, la comprobación devuelve el control a la parte superior del método.

Para la comprobación de este escenario, seleccionar varias ubicaciones. La ubicación en primer lugar se utiliza en la aplicación es TodoAzure.Droid.MainActivity.AuthenticateAsync, que coordina una solicitud de inicio de sesión. El uso de esta ubicación hace que la comprobación de raíz llevará a cabo la detección y respuesta cada vez que comienza el proceso de inicio de sesión.

Por la estrategia de protección, una aplicación que se ejecuta en un dispositivo desbloqueado sale cuando llega en primer lugar el método AuthenticateAsync. Por lo que ¿por qué agregar otros métodos que se producen más adelante en el ciclo de vida de la aplicación como ubicaciones adicionales? Esto sirve para ayudar a la aplicación a defenderse contra la ingeniería inversa. Si un atacante crea una versión modificada de la aplicación que se omite o se quita el código de comprobación de raíz en AuthenticateAsync, estas otras ubicaciones podrá reaccionar frente a un entorno de raíz.

Algunas de estas ubicaciones adicionales se definen en TodoAzure.dll. Esto puede ser sorprendente, porque ese ensamblado contiene lógica comunes a todas las plataformas de Xamarin, no solo Android. ¿Cómo puede Dotfuscator insertar una comprobación de la raíz, que detecta la raíz los dispositivos Android: en un ensamblado independiente de la plataforma? Recuerde que el archivo de configuración de Dotfuscator es específico del proyecto TodoAzure.Droid, que hace referencia al proyecto de TodoAzure. Cuando Dotfuscator modifica TodoAzure.dll, modificará únicamente el ensamblado que Visual Studio o copias de MSBuild para usar en el proyecto actual, TodoAzure.Droid. Ensamblado del proyecto TodoAzure original permanece sin cambios.

Notificación de la aplicación: Comprobaciones pueden notificar los resultados de su detección al código de aplicación. Esto le permite ha personalizado los comportamientos de informes y respuesta, mientras que con las comprobaciones había insertado por identificador de Dotfuscator el trabajo de detección. El código de aplicación que recibe el resultado de la detección se llama a un receptor de notificación de aplicación.

Para satisfacer la estrategia de protección en este escenario, necesaria para que la aplicación, deshabilitar para que futuras ejecuciones de la aplicación se cierre con un mensaje de error. Decidió agregar este deshabilitar lógica en un método, TodoAzure.App.DisableIfCompromised y usarlo como receptor de la comprobación de estableciendo las propiedades de comprobación siguiente:

ApplicationNotificationSinkElement: El tipo de elemento de código; en este caso, un método.
ApplicationNotificationSinkName: El nombre simple del elemento de código; en este caso, DisableIfCompromised.
ApplicationNotificationSinkOwner: El tipo que contiene el elemento de código; en este caso, TodoAzure.App.

Cualquiera de las ubicaciones de la comprobación puede llamar a este método de receptor sea estática y pública. Para que sea compatible con una comprobación, el método es sincrónico (no asincrónicas), toma un argumento bool único y tiene un tipo de valor devuelto void.

Cuando se activa, la comprobación llama al método, pasando el true argumento si el dispositivo se ha modificado y false, en caso contrario. Si este argumento es true, es decir, cuando la comprobación detecta la raíz, el método guarda un valor en el almacenamiento local, que indica la aplicación ahora está deshabilitada. Una propiedad acompañante, IsDisabled, expone el valor guardado:

// 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);

Después de que la aplicación está deshabilitada, futuras ejecuciones necesitan mostrar un mensaje de error y la salida. Para ello, reemplazó TodoAzure.LoginPage.OnAppearing, que se llama justo antes de que se muestra la página de inicio de sesión cuando se inicie la aplicación. Si la aplicación está deshabilitada, este método oculta la página de inicio de sesión, muestra un cuadro de diálogo de error y, a continuación, se cierra.

// 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();
}

Dado que también desea defenderse contra la ingeniería inversa, tardaron pasos adicionales para asegurarse de que la aplicación sería más resistente a ese tipo de ataques. Utilizó un nombre para el valor guardado, AppStatus, impreciso y establezca el valor en un número aleatorio, que oculta el significado del valor. También configurar Dotfuscator para ofuscar la aplicación, cambiar el nombre de los identificadores como DisableIfCompromised, por lo que un atacante ver código descompilado no identificará fácilmente este método como de interés. Para obtener detalles sobre cómo he configurado la ofuscación de cambio de nombre, vea el archivo Léame del ejemplo.

Acción: Mientras que el receptor (el método DisableIfCompromised) establece una propiedad para garantizar que las ejecuciones futuras de la salida de la aplicación, es no propio salir de la aplicación cuando primero se detecta la raíz de un elemento. En su lugar, configurar la comprobación para ello automáticamente, establezca la propiedad acción de comprobación para salir.

Cuando la comprobación detecta un dispositivo desbloqueado, notifica al receptor y, a continuación, sale inmediatamente de la aplicación. Debido a la comprobación, en lugar de por el receptor, realiza esta salida inicial, distribuir varias copias de la lógica de salida a través de la aplicación. Al igual que con varias ubicaciones, varias copias de la lógica de salida permite que la aplicación para defenderse mejor cuando un atacante haya quitado algunas de las evaluaciones de raíz.

Compilar y probar la aplicación

Después de configurar la comprobación de la raíz, cerró la ventana de la comprobación seleccionando Aceptar, a continuación, después de guardar mis cambios en el archivo de configuración de Dotfuscator seleccionando archivo | Guarde el proyecto. He creado TodoAzure.Droid en Visual Studio para probar la aplicación protegida con el fin de comprobar que ha configurado correctamente la comprobación de raíz para exigir la estrategia de protección previsto.

Probar la aplicación en un dispositivo no es raíz y, en un dispositivo desbloqueado y en un emulador. En el dispositivo no modificado, la aplicación funcionaron normalmente, lo que permite iniciar una sesión para ver la lista de tareas pendientes. Sin embargo, en el dispositivo conectado a la raíz y en el emulador, después de seleccionar el botón de inicio de sesión, la aplicación repentinamente cerrado. Después de volver a iniciar la aplicación, la aplicación muestra el cuadro de diálogo de error que se muestra en figura 4; después de que cierre el cuadro de diálogo, la aplicación se cerró una vez más. Para ver la página de inicio de sesión de nuevo, tenía que desinstalar y, a continuación, vuelva a instalar la aplicación.

Figura 4 el TodoAzure.Droid protegido que se ejecuta en un emulador

Resumen

Espero que este artículo ha ayudado a iluminar una manera eficaz detectar y responder a la raíz los dispositivos Android mediante herramientas libre incluidos con Visual Studio. Mientras utiliza una aplicación de ejemplo muy conocido como referencia, puede aplicar las ideas presentadas en este artículo para todos los tipos de aplicaciones de Xamarin.Android y diversas otras estrategias de protección.

Si está interesado en aprender más acerca de las comprobaciones, recomienda leer el artículo de MSDN Magazine anterior. En él, tratan otros tipos de comprobaciones que puede aplicar a las aplicaciones de .NET Framework y cómo utilizar comprobaciones puede evitar las infracciones de datos.

Puede que también esté interesado en las características avanzadas de comprobación y ofuscación de Dotfuscator Professional Edition (bit.ly/2xgEZcs) o la herramienta complementaria para Java y tradicional de aplicaciones Android, protección preferente - DashO (bit.ly/2ffHTrN). Puede mantener actualizados con todos los avances en las comprobaciones y protección preferente siguiendo PreEmptive Solutions en Twitter (twitter.com/preemptive) y visite nuestro blog (preemptive.com/blog).

Una estrategia alternativa de protección

Este artículo presenta una estrategia para detectar y responder a la raíz los dispositivos, pero también son posibles otras estrategias. La estrategia que elija debe ser adecuada para la aplicación, el contexto en el que se utiliza la aplicación y la seguridad puede sufrir desee dirección. A continuación, puede aplicar raíz realiza una comprobación para implementar la estrategia elegida. Por ejemplo, si la aplicación no debe salir bajo ninguna circunstancia, puede configurar una comprobación de raíz para deshabilitar determinadas características cuando se detecta la raíz de un elemento, en lugar de salir de la aplicación.

Una única aplicación deba incluso reaccionar frente a la raíz de un elemento de maneras diferentes según la información que se conoce en tiempo de ejecución. Considere la posibilidad de una aplicación disponible en varias regiones geográficas. Respuesta de la aplicación a la raíz de un elemento que tenga que varían según la región para cumplir con las leyes locales y la normativa, especialmente si la respuesta incluye el envío de informes de incidentes hacia el programador ("llamen home").

Al desarrollar una estrategia de protección, también tiene en cuenta el impacto que tendrá la estrategia sobre los usuarios de la aplicación que han modificado intencionadamente sus dispositivos de buena fe. Estos "usuarios avanzados" pueden ser una parte importante de la base de clientes y no se permiten dispositivos podría controlan ellas fuera de la aplicación. Tendrá que sopesar los riesgos de seguridad asociados a dispositivos contra los riesgos de negocio asociados a alienating los usuarios legítimos de estos dispositivos.

En este artículo, supone que TodoAzure.Droid controla los datos confidenciales y, por lo tanto, para evitar el robo de datos y la ingeniería inversa, dispositivos deben ser totalmente prohibidos. Si en su lugar había trata los datos como no confidenciales, podría ha implementado una estrategia de protección que permite que los dispositivos con raíz en determinadas circunstancias, hace que la aplicación sea más accesible a los usuarios avanzados. En esta estrategia alternativa, en lugar de la aplicación, deshabilitar la aplicación advierte al usuario cuando se detecta un dispositivo desbloqueado. Esta advertencia garantiza que el usuario sea consciente del estado del dispositivo y los riesgos asociados inseguro como robo de credenciales. El usuario puede cancelar el intento de inicio de sesión o aceptar los riesgos y continúe con el registro.

En la rama de advertir a los usuarios del repositorio de GitHub de TodoAzureAuth protegidos, he configuré Dotfuscator CE para proteger TodoAzure.Droid con una raíz de comprobación que implementa esta estrategia alternativa de protección. El archivo Léame en esa bifurcación explica lo más preciso de la configuración.

Observe que esta estrategia alternativa realiza un equilibrio entre la accesibilidad para usuarios avanzados y la amenaza de técnicas de ingeniería inversa. En esta estrategia, actores no válidos aún puede instalar la aplicación en un dispositivo conectado a la raíz para los propósitos de técnicas de ingeniería inversa; el cuadro de diálogo de advertencia no detenerlos. He usado todavía Dotfuscator a ofuscar la aplicación, lo que proporciona un grado de protección frente a técnicas de ingeniería inversa. Una aplicación real podría implementar controles adicionales, como el establecimiento de autenticación especial que se utilizará la aplicación en un dispositivo desbloqueado.

Figura A muestra la advertencia mostrada por la aplicación cuando se ejecuta en un dispositivo desbloqueado.

Figura un TodoAzure.Droid, protegido por esta estrategia alternativa, que se ejecuta en un emulador, cuando el usuario selecciona el botón de inicio de sesión

Joe Sewelles un ingeniero de software y el escritor técnico en el equipo de Dotfuscator de PreEmptive Solutions. Cuando haya escrito previamente para MSDN Magazine y el Blog oficial de Xamarin.

Gracias al siguiente experto técnico de Microsoft por revisar este artículo: David Britch
David Britch trabaja en el grupo de documentación de Xamarin en Microsoft. Cuando haya escrito para una gama de publicaciones de desarrollo de software incluidos libros, documentación de la guía, implementaciones de referencia, notas del producto, vídeos y presencial cursos