> For the complete documentation index, see [llms.txt](https://docs.payments.thalescloud.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.payments.thalescloud.io/classic-push-provisioning/es/guia-del-desarrollador/directrices-de-seguridad/android.md). # 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: {% code overflow="wrap" %} ``` KeyguardManager kgManager = (KeyguardManager) context.getSystemService(Context.KEYGUARD_SERVICE);kgManager.isDeviceSecure() ``` {% endcode %} #### 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 `` 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 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]. {% code overflow="wrap" %} ``` $ 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 ``` {% endcode %} #### 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. {% code overflow="wrap" %} ``` ``` {% endcode %} 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. ```java 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 ```java 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](https://www.guardsquare.com/blog/protecting-against-android-overlay-attacks-guardsquare). #### 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](https://developer.android.com/training/articles/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](https://developer.android.com/topic/security/data). ### 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](https://developer.android.com/training/articles/security-gms-provider) 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](https://mas.owasp.org/MASTG/Android/0x05j-Testing-Resiliency-Against-Reverse-Engineering/#root-detection-and-common-root-detection-methods). #### 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](https://mas.owasp.org/MASTG/Android/0x05j-Testing-Resiliency-Against-Reverse-Engineering/#detection-of-reverse-engineering-tools). #### 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](https://mas.owasp.org/MASTG/Android/0x05j-Testing-Resiliency-Against-Reverse-Engineering/#anti-debugging). #### 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](https://mas.owasp.org/MASTG/Android/0x05j-Testing-Resiliency-Against-Reverse-Engineering/#emulator-detection). #### 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](https://books.nowsecure.com/secure-mobile-development/en/coding-practices/anti-tamper-techniques.html) 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](https://mas.owasp.org/MASTG/Android/0x05j-Testing-Resiliency-Against-Reverse-Engineering/#obfuscation). ### 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: ```java 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](https://developer.android.com/training/articles/security-tips). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.payments.thalescloud.io/classic-push-provisioning/es/guia-del-desarrollador/directrices-de-seguridad/android.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.