Android

Protección a Nivel de Aplicación

Verificar el instalador de su aplicación

Para garantizar que la aplicación se distribuya a través de la tienda oficial Google Play, verifique que el nombre del paquete instalador sea com.android.vending. Esto ayuda a prevenir la distribución por canales laterales y las instalaciones no autorizadas desde fuentes de terceros.

Forzar la actualización de la aplicación

Cuando haya una actualización de seguridad disponible en Google Play, obligue al usuario final a actualizar antes de continuar usando el servicio. Esto garantiza que los usuarios finales siempre usen la versión más reciente con las correcciones de seguridad requeridas.

Almacenar los recursos de la aplicación solo en el almacenamiento interno

Almacenar los recursos de la aplicación en el almacenamiento interno (en lugar del almacenamiento externo) mitiga el riesgo de un ataque "Man-in-the-Disk" (MITD). Esto significa que la aplicación no debería permitirse trasladarse al almacenamiento externo usando el android:installLocation atributo del manifiesto.

Compatibilidad con las versiones del SO soportadas por el SDK

Diseñe la aplicación para ejecutarse en dispositivos con versiones del sistema operativo soportadas por el SDK. Esto ayuda a asegurar una experiencia de usuario final consistente y fiable.

Habilitar la pantalla de bloqueo del dispositivo

Se recomienda que la aplicación verifique que el dispositivo esté protegido con PIN, patrón o contraseña usando el siguiente fragmento de código:

KeyguardManager kgManager = (KeyguardManager) context.getSystemService(Context.KEYGUARD_SERVICE);kgManager.isDeviceSecure()

Prevenir permisos excesivos

Se recomienda que la aplicación declare solo los permisos Android necesarios. De lo contrario, un adversario podría obtener acceso a información privilegiada.

Atributos exportados de seguridad de la plataforma

Las aplicaciones Android están compuestas por uno o más de los siguientes componentes:

• Actividades

• Servicios

• Receptores de difusión

• Proveedores de contenido

Al usar estos componentes, tenga en cuenta los riesgos asociados y las rutas de ataque. La comunicación entre aplicaciones generalmente es arriesgada. Considere exponer solo su actividad principal. Establezca export=false para todos los demás componentes. Si otros componentes deben ser públicos, protégelos con permisos personalizados.

Deshabilitar la depuración de la aplicación en la variante de lanzamiento

Para eliminar el modo de depuración, establezca explícitamente el android:debuggable atributo del <application> elemento a false en el archivo de manifiesto de Android. Asegúrese de que el APK final no sea depurable realizando las siguientes comprobaciones:

aapt d xmltree <myApplication.apk> AndroidManifest.xml

Después de verificar el APK final, asegúrese de que el atributo esté presente con el valor 0x0. Puede automatizar esta comprobación en su proceso de compilación.

Evaluar App Links y Deep Links

Los deep links y app links pueden aumentar la superficie de ataque de la aplicación. Los riesgos comunes incluyen el secuestro de enlaces y la exposición no intencionada de funcionalidad sensible. El comportamiento también difiere según la versión de Android:

• Antes de Android 12 (nivel de API 31), si la aplicación tiene enlaces no verificables, puede provocar que el sistema no verifique todos los Android App Links para esa aplicación.

• A partir de Android 12 (nivel de API 31), las aplicaciones se benefician de una superficie de ataque reducida. A menos que la aplicación de destino esté aprobada para el dominio específico contenido en esa intención web, una intención web genérica se resolverá en la aplicación de navegador predeterminada del usuario final.

Enumere todos los deep links y verifique la asociación correcta con el sitio web. Pruebe a fondo las operaciones soportadas. Trate todos los datos de entrada como no confiables y siempre valídelos. La validación garantiza que solo se procese la información esperada.

Evitar capturas de pantalla autogeneradas

Evite la filtración de datos sensibles mediante capturas de pantalla en primer plano usando el Activity.onCreate método de la aplicación:

getWindow().addFlags(LayoutParams.FLAG_SECURE);.

También puede usar el onPause() método de sus actividades para borrar otra información sensible que no deba mantenerse en memoria mientras la aplicación móvil se ejecuta en segundo plano.

Firma adecuada de la aplicación

Asegúrese de que la compilación de lanzamiento haya sido firmada mediante los esquemas v1 y v2 para Android 7.0 (nivel de API 24) y posteriores, y mediante los tres esquemas para Android 9 (nivel de API 28) y posteriores.

Nota

El desarrollador es el propietario del certificado de firma de código en el APK.

Las firmas de APK se pueden verificar usando la herramienta apksigner que está disponible en [SDK-Path]/build-tools/[version].

$ apksigner verify --verbose Desktop/example.apkVerificado usando el esquema v1 (firma JAR): trueVerificado usando el esquema v2 (APK Signature Scheme v2): true Verificado usando el esquema v3 (APK Signature Scheme v3): true Número de firmantes: 1

Evitar la copia de seguridad de los datos de la aplicación

Para evitar la copia de seguridad de los datos de la aplicación, establezca el atributo allowBackup a false en la etiqueta de la aplicación del AndroidManifest.xml archivo.

<?xml version="1.0" encoding="utf-8"?><manifest xmlns:android="http://schemas.android.com/apk/res/android">    <application        android:allowBackup="false">    </application></manifest>

Por defecto, el atributo android:allowBackup está establecido en true. Cuando esta bandera está establecida en true, el usuario final puede hacer copia de seguridad y restaurar los datos de la aplicación. Esto puede tener consecuencias de seguridad para la aplicación.

La función de copia de seguridad permite que los usuarios finales que han habilitado la depuración USB copien los datos de la aplicación desde el dispositivo. Una vez respaldados, los datos de la aplicación pueden ser leídos por el usuario final.

Establecer allowBackup="false" permite que la aplicación opte por no participar en las capacidades de copia de seguridad y restauración.

Prevenir accesibilidad en pantallas sensibles

El servicio de accesibilidad en Android es una función poderosa que permite a los usuarios finales con discapacidades interactuar con sus dispositivos de nuevas maneras. Sin embargo, también introduce riesgos de seguridad porque los servicios de accesibilidad pueden ser abusados para robar datos sensibles o controlar el dispositivo.

El malware dirigido a aplicaciones bancarias y de pago suele abusar de las funciones de accesibilidad. La aplicación debe determinar si las aplicaciones de accesibilidad necesitan acceso a contenido sensible. Las siguientes técnicas pueden detectar servicios de accesibilidad y reducir la filtración de datos sensibles a través de eventos de accesibilidad. Ejercite precaución al aplicar estas comprobaciones, ya que pueden dificultar el uso de la aplicación para usuarios con discapacidades.

Detectar un servicio de accesibilidad activo

Compruebe si hay servicios de accesibilidad activos ejecutándose actualmente. Si hay algún servicio de accesibilidad presente, puede usar esta técnica para limitar la funcionalidad de su aplicación.

Comprobar la lista de servicios de accesibilidad permitidos

Hay una API del sistema disponible para recuperar los servicios de accesibilidad habilitados y en ejecución. Puede mantener una lista blanca o una lista negra de aplicaciones de accesibilidad y sus capacidades. Si hay servicios de accesibilidad no deseados ejecutándose en segundo plano, advierta al usuario final, aborte la operación o solicite al usuario final que deshabilite esos servicios.

Deshabilitar el acceso de accesibilidad a una vista

Un enfoque alternativo es deshabilitar el acceso de accesibilidad para una vista. Esto evita eventos de accesibilidad desde la vista y sus subvistas.

private void disableAccessibilityEvent() {
    ViewCompat.setImportantForAccessibility(this, ViewCompat.IMPORTANT_FOR_ACCESSIBILITY_NO_HIDE_DESCENDANTS)
}

Evitar que eventos de accesibilidad se emitan desde vistas EditText

Por defecto, el sistema EditText para contraseñas mostrará el valor ingresado por un corto tiempo (por ejemplo 1.5 segundos) antes de enmascararlo en un punto, por lo que los servicios de accesibilidad pueden recibir textos como "***1", "*****3". El siguiente fragmento de código es una forma intuitiva de ocultar tales valores de entrada sensibles de las aplicaciones de accesibilidad

private fun hideLastDigit() {
    transformationMethod = SecureTransformationMethod()
}

class SecureTransformationMethod : PasswordTransformationMethod() {
    override fun getTransformation(source: CharSequence?, view: View?): CharSequence {
        if (source == null) return SecureCharSequence("")
        return SecureCharSequence(source)
    }

    class SecureCharSequence(private val charSequence: CharSequence) : CharSequence {
        override val length: Int
            get() = charSequence.length

        override fun get(index: Int): Char {
            return 'x'
        }

        override fun subSequence(startIndex: Int, endIndex: Int): CharSequence {
            return SecureCharSequence(charSequence.subSequence(startIndex, endIndex))
        }
    }
}

Prevenir ataques de superposición (overlay)

Las superposiciones de Android permiten que una aplicación dibuje sobre otra aplicación. Pueden mejorar la experiencia del usuario. También pueden ser abusadas para phishing, escalada de privilegios y robo de datos. La API de Android 9 introdujo métodos para detectar superposiciones basadas en eventos táctiles: onTouch, onFilterTouchEventForSecurity, y setFilterTouchesWhenObscured. En API 31 y posteriores, está protegido contra superposiciones no del sistema para cada vista donde llame a setHideOverlayWindows(true). En niveles de API inferiores a 31, la aplicación aún puede ser vulnerable a superposiciones que no transmiten eventos táctiles. Para más detalles, consulte Protección contra ataques de superposición en Android.

Usar teclado propietario

No se recomienda usar teclados de terceros para ingresar información sensible como un PIN, contraseña o PII. Prefiera un teclado propietario usado solo por la aplicación. Esto reduce el riesgo de que teclados de terceros capturen entradas sensibles.

Si un teclado propietario no es posible, prefiera un teclado numérico PIN personalizado. También puede barajar la disposición del teclado PIN. Barajar genera una disposición de teclas aleatoria en la pantalla. Esto ayuda a mitigar el shoulder surfing y los ataques de malware basados en accesibilidad.

Protección de datos

Datos en tránsito

La aplicación debe usar TLS 1.2 o TLS 1.3. Configure el servidor para usar suites de cifrado fuertes. También aplique las siguientes medidas para proteger los datos en tránsito:

Pinning de certificados

La aplicación debería usar pinning de certificados para toda la comunicación con el servidor. A partir de Android 7.0, puede usar Network Security Configuration para aplicar pinning de certificados para los dominios con los que la aplicación se comunica. Consulte Network Security Config para más detalles.

Proteger los datos con cifrado

La aplicación debe extremar las precauciones al enviar datos sensibles, como información de identificación personal (PII), a su servidor. Se recomienda aplicar confidencialidad y autenticación además de las protecciones TLS.

Datos en reposo

La aplicación debe proteger los datos sensibles, incluso cuando se almacenan dentro del sandbox de la aplicación. El malware con privilegios aún puede acceder a datos en el sandbox. Aplique confidencialidad, autenticación y propiedades de seguridad vinculadas al dispositivo al almacenar datos sensibles. En Android, las aplicaciones pueden usar EncryptedSharedPreference o EncryptedFile para cumplir con estos requisitos. Para más información, consulte Proteger los datos en reposo.

Autenticación

Habilitar autenticación biométrica

La aplicación debe habilitar la autenticación biométrica para el inicio de sesión del usuario final. Al usar autenticación biométrica, se recomienda usar Android Keystore y autenticación basada en objetos criptográficos biométricos para una seguridad más robusta. Esto también ayuda a detectar cuando se agregan o eliminan datos biométricos.

Hacer cumplir la autenticación multifactor

Hacer cumplir la autenticación multifactor (MFA) es una medida de seguridad crucial para proteger operaciones sensibles del SDK y la aplicación. MFA añade una capa extra de seguridad al requerir que los usuarios proporcionen múltiples formas de autenticación antes de acceder a funciones o datos sensibles. Esto puede reducir considerablemente el riesgo de acceso no autorizado incluso si se ve comprometido el factor de autenticación principal del usuario.

Directrices de criptografía

Proveedores de seguridad

Se recomienda usar el proveedor de seguridad actualizado de Google Play services para proteger contra vulnerabilidades futuras en los proveedores criptográficos de la plataforma.

Debido a que el Thales TPC SDK no es responsable de actualizar o notificar al usuario final, la aplicación debe asegurarse de que el proveedor de seguridad de Google Play services esté actualizado en el dispositivo del usuario final.

Generación segura de números aleatorios

La aplicación siempre debe usar métodos de la clase SecureRandom para generar claves criptográficas sensibles y otros valores aleatorios. Para el nivel de API 29 y posteriores, se recomienda usar SecureRandom.getInstanceStrong() para confiar en el proveedor de seguridad predeterminado de la plataforma en lugar de un proveedor proporcionado por la aplicación.

Endurecimiento de la aplicación

Detectar dispositivos rooteados

Detecte un entorno de dispositivo comprometido, como frameworks de root y binarios de superusuario, antes de inicializar la aplicación y antes de realizar cualquier operación sensible. Para más detalles, consulte Métodos comunes de detección de root.

Detectar hooking en la aplicación

El hooking inyecta una carga en el proceso de la aplicación. Los atacantes lo usan para interceptar datos sensibles como claves criptográficas y PII, estudiar mecanismos de seguridad o cambiar el flujo de la aplicación. Las aplicaciones deben detectar intentos de hooking. Para más detalles, consulte Métodos de detección de hooking.

Detectar adjunto de depurador

En dispositivos comprometidos, un atacante puede adjuntar un depurador a la variante de lanzamiento de la aplicación. Esto les permite depurar el flujo de la aplicación tanto en binarios nativos como en Java/Kotlin. Detecte depuradores en código Java/Kotlin y nativo, especialmente antes de ejecutar operaciones sensibles. Para más detalles, consulte Métodos de detección de depuración.

Detectar emulador

Los emuladores pueden ofrecer un entorno menos confiable y permitir análisis dinámico. Detecte el uso de emuladores al inicio de la aplicación. Para más detalles, consulte Detección de emuladores.

Detectar manipulación de la aplicación

Para prevenir la alteración maliciosa del código de la aplicación, se recomienda verificar el hash de la firma del certificado de firma de la aplicación en tiempo de ejecución. Los atacantes no pueden replicar esta firma cuando firman la aplicación después de manipular el binario o cualquier archivo de recursos. Sin embargo, se requiere una obfuscación fuerte para proteger el hash del certificado de firma dentro del binario contra modificaciones. Consulte Detección de manipulación de la aplicación para más detalles.

Además, la aplicación también puede comunicar el hash de la firma del certificado de firma al servidor de la aplicación. El servidor de la aplicación verifica que el hash de la firma coincida con los valores de hash de la aplicación configurados antes de aceptar más solicitudes del cliente.

Ofuscar la aplicación

La aplicación y todos sus componentes deben ser ofuscados. Esto aumenta la complejidad para que un atacante realice ingeniería inversa de la aplicación móvil y descubra los algoritmos utilizados o identifique sus datos secretos.

Aunque el Thales TPC SDK ya está ofuscado usando DexGuard, sigue siendo importante que la aplicación ofusque las APIs públicas del Thales TPC SDK aplicando las reglas compartidas con los paquetes binarios. Es extremadamente importante seguir las recomendaciones de ofuscación proporcionadas y prestar especial atención a:

-flattenpackagehierachy util

Se recomienda usar el nombre de paquete 'util' para asegurar consistencia en la ofuscación. Existen herramientas comerciales disponibles para ofuscación. Para Android, la recomendación actual es usar DexGuard. Para más información sobre ofuscación, consulte Herramientas y técnicas de ofuscación.

Codificación segura

Borrado de datos sensibles en Android

Almacene datos sensibles como claves criptográficas, PII y otros datos sensibles del usuario final en arreglos de bytes. En Java, no puede alterar el comportamiento subyacente de objetos como String y StringBuilder. Tampoco puede controlar cuántas copias existen en la memoria a lo largo del tiempo.

Se recomienda encarecidamente borrar los datos sensibles usted mismo en lugar de depender del recolector de basura. Siempre use un bloque finally para que los datos se borren incluso si ocurre una excepción, como se muestra en el siguiente fragmento de código:

byte[] password = this.getUserPassword();
try {
  // Use la contraseña para iniciar sesión
  this.logUserIn(password);
} finally {
  	// Incluso si no hay un catch de excepción aquí, puede haber una
  	//RuntimeException que todavía debería activar este bloque finally
  	// para ejecutarse
  MemoryHelper.clearData(password);
}

//Una forma de implementar un método de borrado de arreglos de bytes es reescribir cada elemento en los arreglos en la clase MemoryHelper
class public static void clearData(byte[] baBuffer) {
  if (baBuffer == null)
    return;
  for(i = 0;  i < baBuffer.length; i++) {
    baBuffer[i] = (byte)0;
  }
}

Reglas de codificación segura

Reúna directrices de codificación segura de fuentes confiables como Apple, Google y OWASP (Open Web Application Security Project). También puede contactar con la Comunidad de Seguridad de Handset de Thales para obtener acceso a estas directrices.

También se recomienda usar herramientas de análisis estático de código (como PMD o HP Fortify) para hacer cumplir estas directrices.

Usar la herramienta Lint

Antes de que cada función esté completa, y antes de la finalización de la entrega final, use lint para identificar y corregir cualquier problema de seguridad.

La documentación de Android describe lint como una herramienta de análisis estático de código. Revisa los archivos fuente del proyecto en busca de posibles errores y oportunidades de optimización relacionadas con corrección, seguridad, rendimiento, usabilidad, accesibilidad e internacionalización.

La lista completa de comprobaciones realizadas por lint puede consultarse en el sitio web de desarrolladores de Android.

Consejos generales de seguridad en Android

Conozca y siga las características y tecnologías de seguridad proporcionadas por Android. Vea Consejos de seguridad de Android.