> 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/merchant-tokenization/es/integracion-del-sdk/security/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 Google Play Store oficial, debe verificar que el nombre del paquete del instalador sea com.android.vending. Esto ayuda a prevenir la distribución por canales secundarios o instalaciones no autorizadas desde fuentes de terceros.
### Forzar la Actualización de la Aplicación
Siempre que haya una actualización de seguridad disponible para su aplicación en Play Store, su aplicación debe forzar la actualización antes de que el usuario final pueda seguir usando el servicio. Esto garantiza que los usuarios finales siempre usen la versión más reciente de la aplicación con las correcciones de seguridad necesarias.
### 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 debe permitirse ser movida al almacenamiento externo usando el `android:installLocation` atributo del manifiesto.
### Compatibilidad con las Versiones de SO Admitidas por el SDK
La aplicación debe estar diseñada para ejecutarse en dispositivos con versiones del SO admitidas por el SDK. Esto asegura que los usuarios finales tengan una experiencia coherente y fiable al usar la aplicación.
### 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:
```java
KeyguardManager kgManager = (KeyguardManager) context.getSystemService(Context.KEYGUARD_SERVICE);
kgManager.isDeviceSecure()
```
### Evitar Permisos Excesivos
Se recomienda que la aplicación declare únicamente los permisos de Android necesarios; de lo contrario, un adversario puede obtener acceso a información privilegiada.
### Atributos Exportados de Seguridad de la Plataforma
Las aplicaciones Android se componen de uno o más de los siguientes componentes:
* Actividades
* Servicios
* Receptores de difusión (Broadcast receivers)
* Proveedores de contenido
Al usar cada uno de estos componentes, esté atento a los posibles riesgos y a los ataques asociados. En general, la comunicación entre aplicaciones es arriesgada. Considere diseñar su aplicación móvil dejando accesible públicamente solo su actividad principal. Todos los demás componentes deben tener explícitamente el atributo `export=false`. Para que otros componentes sean públicos, considere protegerlos con permisos personalizados.
### Deshabilitar la Depuración de la Aplicación en la Variante de Release
Para eliminar el modo de depuración, debe establecer 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:
```shellscript
aapt d xmltree AndroidManifest.xml
```
Después de verificar el APK final, asegúrese de que el atributo esté presente con un valor 0x0. Puede automatizar esta verificación en el proceso de compilación.
### Evaluar App Links y Deep Links
Cualquier deep link y app link existente puede aumentar potencialmente la superficie de ataque de la aplicación. Esto incluye varios riesgos de seguridad como el secuestro de enlaces, la exposición de funcionalidades sensibles como en las siguientes versiones de Android:
* Antes de Android 12 (nivel de API 31), si la aplicación tiene enlaces no verificables, esto puede causar 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 destinataria esté aprobada para el dominio específico contenido en esa intención web, una intención web genérica se resuelve en la aplicación de navegador predeterminada del usuario final.
Todos los deep links deben enumerarse y verificarse para una asociación correcta con el sitio web. Las operaciones realizadas deben probarse exhaustivamente; especialmente todos los datos de entrada que se consideren no confiables siempre deben validarse. La validación garantiza que solo se procesen los datos que la aplicación espera.
### Prevenir Capturas de Pantalla Auto-Generadas
La filtración de datos sensibles a través de capturas de pantalla en primer plano se puede prevenir usando el `Activity.onCreate` método de la aplicación:
```java
getWindow().addFlags(LayoutParams.FLAG_SECURE);.
```
También puede usar el `onPause()` método de sus actividades para borrar otra información sensible que no debe permanecer en la 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 release 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.
{% hint style="info" %}
El desarrollador es el propietario del certificado de firma de código en el APK.
{% endhint %}
Las firmas APK pueden verificarse usando la herramienta apksigner, disponible en \[SDK-Path]/build-tools/\[version].
```shellscript
$ apksigner verify --verbose Desktop/example.apk
Verificado usando el esquema v1 (firma JAR): true
Verificado usando el esquema v2 (APK Signature Scheme v2): true Verificado usando el esquema v3 (APK Signature Scheme v3): true Número de firmantes: 1
```
### Prevenir la Copia de Seguridad de los Datos de la Aplicación
Para prevenir la copia de seguridad de los datos de la aplicación, establezca el atributo `allowBackup` a `false` en la etiqueta application del `AndroidManifest.xml` archivo.
```xml
```
Por defecto, el atributo `android:allowBackup` está establecido en `true`. Cuando este indicador está establecido en `true`, los datos de la aplicación pueden ser respaldados y restaurados por el usuario final. Sin embargo, esto puede tener consecuencias de seguridad para una aplicación.
La función de copia de seguridad permite a los usuarios finales que han habilitado la depuración USB copiar los datos de la aplicación desde el dispositivo. Una vez que los datos están respaldados, todos 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 usar las capacidades de copia de seguridad y restauración.
### Prevenir el Acceso por Accesibilidad en Pantallas Sensibles
El servicio de accesibilidad en Android es una función poderosa que permite a usuarios con discapacidades interactuar con sus dispositivos de nuevas maneras. Sin embargo, esta funcionalidad también conlleva riesgos de seguridad potenciales, ya que el servicio de accesibilidad puede ser abusado para robar datos sensibles o controlar el dispositivo.
Dado que hay un número creciente de malware que atacan aplicaciones bancarias y de pago móviles, la aplicación determina si contenidos sensibles necesitan ser leídos por las aplicaciones de accesibilidad instaladas en el dispositivo. Las siguientes técnicas se usan para detectar la presencia de aplicaciones de accesibilidad y para evitar que datos sensibles se emitan a través de eventos de accesibilidad. Tenga precaución al realizar las siguientes comprobaciones ya que pueden dificultar el uso de su aplicación a 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 obtener los servicios de accesibilidad habilitados y en ejecución. Puede mantener una lista blanca/lista negra de las aplicaciones de accesibilidad permitidas y sus capacidades. Si hay servicios de accesibilidad no deseados ejecutándose en segundo plano, puede advertir al usuario final, abortar la operación o solicitar al usuario final que desactive los servicios de accesibilidad.
### **Deshabilitar el Acceso de Accesibilidad a una Vista**
Una alternativa para detectar aplicaciones de accesibilidad instaladas en el dispositivo es deshabilitar el acceso de accesibilidad de una vista. Esto impedirá todos los eventos de accesibilidad provenientes de la vista y sus subviews.
```java
private void disableAccessibilityEvent() {
ViewCompat.setImportantForAccessibility(this, ViewCompat.IMPORTANT_FOR_ACCESSIBILITY_NO_HIDE_DESCENDANTS)
}
```
### **Prevenir la Emisión de Eventos de Accesibilidad desde Vistas EditText**
Por defecto, el sistema `EditText` para contraseñas mostrará el valor introducido por un breve periodo (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 manera 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)
La superposición (overlay) de Android es una función que usa una aplicación para aparecer encima de otra aplicación. A menudo se usan para proporcionar una experiencia de usuario más conveniente al permitir a los usuarios acceder a ciertas funciones o información sin salir de la aplicación que están usando. Sin embargo, los beneficios de esta función conllevan un gran riesgo, ya que las superposiciones de Android pueden, desafortunadamente, usarse con fines maliciosos. La escalada de privilegios y el robo de datos sensibles son con frecuencia el resultado de ataques de superposición exitosos. Las superposiciones pueden dibujar una ventana completa encima de una aplicación legítima para suplantar la aplicación especificada y aumentar la probabilidad de conducir un ataque de phishing exitoso. Para protegerse contra ataques de superposición, la API de Android 9 (Android 2) agregó tres métodos valiosos para detectar superposiciones basadas en eventos táctiles. Los métodos `onTouch`, `onFilterTouchEventForSecurity`, y `setFilterTouchesWhenObscured` están disponibles en la API 9 y posteriores y pueden usarse para detectar eventos táctiles oscurecidos. En API 31+, está totalmente protegido contra cualquier superposición que no sea del sistema para cada vista en la que se llame a la API `setHideOverlayWindows(true)` Sin embargo, cualquier API por debajo de la 31 puede ser vulnerable a superposiciones que no transmiten los 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 PIN del usuario, contraseña o cualquier información PII. Se prefiere un teclado propietario utilizado únicamente por la aplicación móvil. Esto impide que un teclado de terceros registre las entradas sensibles del usuario final.
Si no es posible tener un teclado propietario, se prefiere un teclado numérico (PIN pad) personalizado para el código de acceso. También se puede implementar un reordenamiento aleatorio del diseño del PIN pad. El reordenamiento funciona generando un diseño aleatorio para las teclas en la pantalla. Esto ayuda a mitigar ataques comunes de observación por el hombro y ataques de malware de accesibilidad.
## Protección de Datos
### Datos en Tránsito
La aplicación debe usar TLS 1.2 o TLS 1.3. El servidor se configurará para usar conjuntos de cifrado fuertes. Además, se deben usar los siguientes métodos para la protección de datos en tránsito:
### **Fijación de Certificados (Certificate Pinning)**
La aplicación emplea certificate pinning para toda su comunicación con el servidor. Desde Android v7.0, la aplicación puede usar la configuración de seguridad de red (Network Security configuration) para aplicar el certificate pinning en todos los dominios con los que se comunique. 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 comunicar datos sensibles como Información de Identificación Personal (PII) a su servidor. Se recomienda aplicar confidencialidad y autenticación de los datos además de las protecciones TLS.
### Datos en Reposo
La aplicación debe proteger los datos sensibles incluso si se almacenan dentro del sandbox de la aplicación. Un malware privilegiado puede acceder a datos sensibles incluso si están almacenados dentro del sandbox. La aplicación debe aplicar las propiedades de confidencialidad, autenticación y seguridad ligada al dispositivo al almacenar datos sensibles. En Android, las aplicaciones pueden hacer uso de `EncryptedSharedPreference` o `EncryptedFile` que satisface todas las propiedades de seguridad necesarias para tratar los datos sensibles antes de almacenarlos en el sandbox de la aplicación. Para más información sobre cómo proteger los datos en reposo, consulte [Protección de datos en reposo](https://developer.android.com/topic/security/data).
## Autenticación
### Habilitar la 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 hacer uso del Keystore de Android y de la autenticación basada en objetos Biometric Crypto, que ofrecen mejor seguridad. Esto también asegura que cualquier adición o eliminación de datos biométricos pueda detectarse.
### Aplicar Autenticación Multifactor
Aplicar la autenticación multifactor (MFA) es una medida de seguridad crucial para proteger operaciones sensibles del SDK y la aplicación. MFA agrega una capa extra de seguridad al exigir a los usuarios que proporcionen múltiples formas de autenticación antes de acceder a funciones o datos sensibles. Esto puede reducir en gran medida el riesgo de acceso no autorizado incluso si se compromete el factor de autenticación primario del usuario final.
## 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 dinámicamente contra futuras vulnerabilidades del Proveedor de Criptografía de la Plataforma.
Como Thales SDK no es responsable de actualizar o notificar al usuario final para instalar o actualizar el Proveedor de Seguridad de Google Play Services, la aplicación garantizará que este 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 debe usar siempre los métodos de la clase `SecureRandom` para generar cualquier clave criptográfica sensible o para cualquier generación de datos aleatorios. Para nivel de API 29 en adelante, se recomienda usar la API `SecureRandom.getInstanceStrong()` para usar el proveedor de seguridad predeterminado de la plataforma en lugar del proveedor de seguridad proporcionado por la aplicación.
## Endurecimiento de la Aplicación
### Detectar Dispositivos Rooteados
La aplicación detecta entornos de dispositivo comprometidos, como frameworks de root y binarios de superusuario, antes de inicializar la aplicación y antes de realizar operaciones sensibles. Para más detalles sobre detección integral de root, 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 es un proceso de inyectar una carga útil para ejecutarse en el contexto del proceso de la aplicación con el propósito de interceptar datos sensibles como claves criptográficas, datos PII, entender los mecanismos de seguridad de la aplicación o incluso cambiar el flujo de la aplicación. Por lo tanto, las aplicaciones deben esforzarse por detectar cualquier intento de hookear la aplicación. Para más detalles sobre cómo realizar una detección de hooks, consulte [Métodos de Detección de Hooks](https://mas.owasp.org/MASTG/Android/0x05j-Testing-Resiliency-Against-Reverse-Engineering/#detection-of-reverse-engineering-tools).
### Detectar la Conexión de un Depurador
Un depurador puede adjuntarse a la variante de release de la aplicación en dispositivos comprometidos. Con los depuradores, un adversario puede depurar el flujo de la aplicación tanto en binarios nativos como en Java/Kotlin. Es importante que las aplicaciones detecten depuradores en binarios Java/Kotlin y nativos, especialmente antes de ejecutar operaciones sensibles. Para más información sobre la detección de depuradores, 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 proporcionan un entorno comprometido al ejecutar aplicaciones, lo que permite a los adversarios realizar diversos análisis dinámicos. Se recomienda detectar el emulador al inicio de la aplicación. Para más detalles sobre la detección de emuladores, consulte [Detección de Emulador](https://mas.owasp.org/MASTG/Android/0x05j-Testing-Resiliency-Against-Reverse-Engineering/#emulator-detection).
### Detectar Manipulación de la Aplicación
Para prevenir modificaciones maliciosas en el 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 ofuscació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 configurados de la aplicación 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 reverse-engineeree la aplicación móvil y descubra los algoritmos usados o identifique sus datos secretos.
Aunque Thales SDK ya está ofuscado usando *DexGuard*, sigue siendo importante que la aplicación ofusque las APIs públicas del Thales 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:copy:
Se recomienda usar el nombre de paquete 'util' para asegurar la 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
Todos los datos sensibles como claves criptográficas, PII o cualquier información sensible del usuario deben almacenarse en arreglos de bytes. En Java, no es posible alterar el comportamiento de la estructura de datos subyacente de objetos como `String` y `StringBuilder`, y no hay control sobre cuántas copias de los datos se hacen en la memoria, así como qué puede suceder con ellas con el paso del tiempo.
Se recomienda encarecidamente borrar los datos sensibles por su cuenta en lugar de confiar en el recolector de basura para desecharlos. Para asegurar que ninguna excepción pueda pasar por el flujo de ejecución y provocar una fuga de datos sensibles, siempre use el bloque `finally` para borrar los datos sensibles incluso si no se utiliza ningún bloque catch, como se muestra en el siguiente fragmento de código:
```java
byte[] password = this.getUserPassword();
try {
// Use the password to login
this.logUserIn(password);
} finally {
// Even if there is no exception catch here, there can be a
//RuntimeException that should still trigger this finally block
// to execute
MemoryHelper.clearData(password);
}
//One way to implement a byte array wiping method is to rewrite every element in the arrays in the 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, OWASP (Open Web Application Security Project). Alternativamente, 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 entrega final, use lint para identificar y corregir cualquier problema de seguridad.
Desde el sitio web de Android, se indica que lint es una herramienta de análisis estático de código que comprueba los archivos fuente de su proyecto Android en busca de posibles errores y mejoras de optimización para 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
Se recomienda estar al tanto y seguir las características y tecnologías de seguridad provistas 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/merchant-tokenization/es/integracion-del-sdk/security/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.