Mejores prácticas de aplicaciones seguras para mejorar la ciberseguridad.

En la era de los vectores elevados y muy variados de las amenazas a la ciberseguridad, mantener una buena higiene para proteger a los usuarios de su aplicación es fundamental no sólo para el desarrollador de una aplicación, sino también para la seguridad del consumidor y del usuario de la aplicación.

Aunque la estrategia y las técnicas elegidas para proteger la seguridad de los usuarios de aplicaciones dependerán de la funcionalidad que la aplicación ofrezca a los usuarios, los desarrolladores deberían tener presentes las siguientes prácticas:

Autenticación
Autorización
Almacenamiento de datos
Antimanipulación y antirretroceso

Profundicemos en cada una de las 4 áreas.

Autenticación

Validar la identidad del usuario y garantizar un acceso legítimo. Algunos ejemplos son la biometría, los números de identificación personal o los generadores de códigos de autenticación multifactor.

Implemente la autenticación "Algo que sabe" como uno de los factores de la AMF.

Something-You-Know representa una capa fundamental de verificación de identidad que implica información que sólo conoce el usuario, como un PIN (número de identificación personal), una contraseña, un patrón, etc.

La implementación de Algo-Tú-Sabes como uno de los factores de la AMF garantiza un nivel básico de verificación de la identidad al exigir a los usuarios que proporcionen información única asociada a sus cuentas.

Implemente la autenticación Algo-Tiene como uno de los factores MFA.

Something-You-Have requiere que los usuarios se autentiquen con un dispositivo físico, una aplicación o un token que genere credenciales de autenticación, que pueden incluir contraseñas de un solo uso (OTP) basadas en el tiempo. Ejemplos de este tipo de tokens son los tokens de software, los tokens de hardware y las OTP por SMS.

Implementar Algo-Tu-Tienes como uno de los factores de la AMF añade complejidad al proceso de autenticación al requerir la posesión de un elemento tangible, lo que reduce significativamente la probabilidad de acceso no autorizado.

Los desarrolladores deben utilizar una OTP basada en tiempo para tokens de software, tokens de hardware y OTP por SMS. Deben seguirse las siguientes directrices:

Una OTP sólo debe ser válida durante un máximo de 30 segundos.
Una OTP introducida incorrectamente después de 3 intentos debe ser invalidada, y la sesión del usuario debe ser revocada o rechazada.

Implemente la autenticación "Algo que usted es" como uno de los factores MFA.

Something-You-Are requiere que los usuarios se autentiquen con identificadores biométricos como huellas dactilares, escáneres de retina o reconocimiento facial.

La implementación de Algo-Tú-Eres como uno de los factores de la AMF añade un factor de autenticación altamente personalizado y difícil de replicar. Proporciona un medio más sólido de verificar la identidad del usuario que los factores Algo que sabes y Algo que tienes, reduciendo el riesgo de acceso no autorizado.

Los desarrolladores deben limitar las funcionalidades de las aplicaciones en dispositivos que carezcan de hardware Trusted Executed Environment (TEE) o biometría (por ejemplo, los dispositivos Android que carezcan de TEE pueden detectarse mediante la API de Android "isInsideSecureHardware") e invalidar la autenticación biométrica si se producen cambios en el mecanismo biométrico, como el registro de una nueva huella dactilar en el dispositivo. Tanto las plataformas iOS como Android admiten la configuración de una clave criptográfica de aplicación para que caduque en respuesta a dichos cambios.

Utilice factores basados en el contexto para autenticarse.

Los factores basados en el contexto introducen elementos dinámicos como la ubicación del usuario y los atributos del dispositivo. Aunque la AMF proporciona una sólida capa de seguridad al requerir múltiples factores de autenticación, la incorporación de factores basados en el contexto crea un proceso de autenticación más completo y adaptable que puede ofrecer ventajas adicionales a la hora de abordar los riesgos cambiantes del acceso no autorizado.

La implementación de factores basados en el contexto minimiza la dependencia de credenciales estáticas, lo que dificulta a los actores maliciosos el intento de acceso no autorizado. Los desarrolladores deben tener en cuenta los siguientes factores contextuales para verificar la identidad de un usuario:

Geolocalización: Permita el acceso en función de la ubicación real de un dispositivo mediante geolocalización por GPS, Wi-Fi o dirección IP.
Tipo de dispositivo: Permitir el acceso en función de las características de un dispositivo. Por ejemplo, el tamaño de la pantalla puede determinar si un dispositivo es un smartphone o una tableta.

Implantar una autenticación de sesión segura.

La autenticación de sesión segura garantiza una sólida gestión de las sesiones, tanto para la autenticación con estado como para la autenticación sin estado. Las sesiones mal gestionadas, independientemente de si la aplicación sigue métodos de autenticación con o sin estado, pueden dar lugar a amenazas de seguridad como accesos no autorizados, secuestro de sesiones o violación de datos.

La autenticación de sesión segura para sesiones con estado emplea identificadores de sesión seguros, comunicación cifrada y tiempos de espera adecuados para impedir el acceso no autorizado. Para la autenticación sin estado, garantiza que los tokens sean resistentes a la manipulación, manteniendo la integridad de la autenticación sin depender del almacenamiento en el servidor.

Implantar una autenticación segura con estado.

La autenticación segura con estado implica proteger y mantener sesiones persistentes. Aunque la autenticación con estado proporciona una experiencia de usuario fluida gracias a las sesiones de usuario persistentes, puede ser vulnerable a varias amenazas de seguridad, como los actores maliciosos que intentan robar identificadores de sesión.

Implementar una autenticación segura con estado protege las cuentas de usuario de accesos no autorizados y de posibles vulnerabilidades asociadas a la gestión de sesiones sin comprometer el equilibrio entre usabilidad y seguridad.

Los desarrolladores deben identificar los puntos finales del lado del servidor que exponen información sensible o funcionalidades críticas y adoptar las siguientes mejores prácticas de autenticación de sesión con estado:

Rechazar solicitudes con identificadores de sesión o tokens que falten o no sean válidos.
Generar identificadores de sesión aleatoriamente en el lado del servidor sin añadirlos a las URL.
Aumentar la seguridad del identificador de sesión con la longitud y entropía adecuadas, dificultando su adivinación.
Intercambie identificadores de sesión sólo a través de conexiones HTTPS seguras.
Evite almacenar los identificadores de sesión en el almacenamiento persistente.
Verificar los identificadores de sesión para el acceso de los usuarios a los elementos privilegiados de la aplicación.
Finaliza las sesiones en el lado del servidor, borrando la información de la sesión cuando se agota el tiempo de espera o se cierra la sesión.

Implantar una autenticación segura sin estado.

La autenticación apátrida segura implica prácticas de tokens seguros para una autenticación eficaz y escalable
. Aunque la autenticación sin estado ofrece ventajas, puede ser más vulnerable a amenazas de seguridad como la suplantación de identidad si los tokens no se generan, transmiten y almacenan de forma segura.

Implementar una autenticación segura sin estado garantiza que cada token de autenticación se gestiona de forma segura al tiempo que se obtienen las ventajas de la eficiencia y la escalabilidad, reduciendo el riesgo de accesos no autorizados. Los desarrolladores deben adoptar las siguientes buenas prácticas de autenticación de sesiones sin estado:

Generar tokens en el lado del servidor sin añadirlos a las URL.
Aumente la seguridad de los tokens con la longitud y entropía adecuadas, dificultando su adivinación.
Intercambie tokens sólo a través de conexiones HTTPS seguras.
Compruebe que no hay datos confidenciales, como información de identificación personal, incrustados en los tokens.
Evite almacenar tokens en almacenamiento persistente.
Verificar tokens para el acceso de usuarios a elementos privilegiados de la app.
Termina los tokens en el lado del servidor, borrando la información de los tokens cuando se agota el tiempo de espera o se cierra la sesión.
Firmar criptográficamente los tokens utilizando un algoritmo seguro, evitando el uso de algoritmos nulos.

Implemente la finalización segura de la sesión durante el cierre de sesión, la inactividad o el cierre de la aplicación.

La terminación segura de sesiones garantiza el cierre efectivo de las sesiones de usuario. En situaciones como el cierre de sesión, la inactividad o el cierre de la aplicación, existe la posibilidad de que agentes maliciosos exploten cualquier punto de acceso persistente si las sesiones no se gestionan adecuadamente.
La implementación de la finalización de sesión segura durante el cierre de sesión, la inactividad o el cierre de la aplicación puede reducir significativamente el riesgo de acceso no autorizado al finalizar automáticamente las sesiones de usuario y proteger la información del usuario frente al acceso de terceros no autorizados. Los desarrolladores deben:

volver a autenticar a los usuarios después de cerrar la sesión, inactividad de la aplicación, inactividad, fondo, tiempo de espera de sesión absoluto o cierre abrupto/fuerza.
generar nuevos identificadores de sesión en el servidor cada vez que los usuarios pasen a un nuevo nivel de autenticación para evitar la fijación de sesión.
garantizar que la finalización de la sesión incluya la eliminación o desautorización de todos los tokens o identificadores de sesión almacenados localmente en
.
determinar el valor del tiempo de espera de inactividad en función del riesgo y la naturaleza de la funcionalidad.

Implementar la protección de fuerza bruta para la autenticación.

Los ataques de fuerza bruta consisten en intentos automatizados y sistemáticos de adivinar las credenciales de los usuarios, por ejemplo, probando varias combinaciones de nombres de usuario y contraseñas para obtener un acceso no autorizado.

La protección por fuerza bruta restringe el número de intentos de inicio de sesión dentro de un periodo determinado. Implementar la protección de fuerza bruta para la autenticación puede mitigar significativamente el riesgo de acceso no autorizado, proteger las cuentas de usuario y mantener la integridad del proceso de autenticación. Los desarrolladores deben implementar mecanismos de fuerza bruta a través de las siguientes mejores prácticas:

Implantar controles antiautomatización.
Aplicar limitación de velocidad para los intentos de inicio de sesión.
Incorpore retardos progresivos (por ejemplo, 30 segundos, 1 minuto, 2 minutos, 5 minutos) para los intentos de inicio de sesión.

Tenga en cuenta que todos los mecanismos de AMF son vulnerables a la fuerza bruta, y es importante comunicar los motivos del bloqueo de la cuenta y proporcionar medios accesibles para que los usuarios se autentiquen y eliminen el bloqueo. Por ejemplo, llamando a la línea de ayuda
o utilizando la verificación biométrica.

Implementar un mecanismo de verificación de la integridad de las transacciones.

Aunque la autenticación garantiza la identidad del usuario, no elimina la posibilidad de actividades fraudulentas durante el proceso de transacción. Los mecanismos de verificación de la integridad de las transacciones son funciones de seguridad auxiliares que dan a los usuarios tiempo y herramientas para reaccionar ante posibles fraudes. La implantación de un mecanismo de verificación de la integridad de las transacciones garantiza que cada transacción se somete a un examen minucioso para confirmar su exactitud y autenticidad.

Los desarrolladores pueden aplicar las siguientes buenas prácticas sugeridas:

Iniciar una llamada de verificación/confirmación de transacción.
Proporcionar un historial de transacciones en tiempo real.
Implantar un periodo de enfriamiento de 12 a 24 horas.
Desactivar las transacciones en el extranjero por defecto; activar sólo a través de MFA.

Autorización

Definir y validar los derechos de acceso de los usuarios a los recursos pertinentes dentro de la aplicación.

Implementa la autorización del lado del servidor.

La autorización del lado del servidor se refiere a la validación y concesión de permisos de acceso a usuarios o aplicaciones por parte de un servidor o un servidor de autorización. Esto garantiza que las decisiones de control de acceso y los permisos se gestionen y apliquen en el servidor en lugar de en el cliente o el dispositivo. Al implementar la autorización del lado del servidor, los desarrolladores reducen las oportunidades de que los atacantes maliciosos manipulen o eludan las medidas de seguridad de la aplicación para obtener acceso no autorizado a datos sensibles (es decir, PII y datos de autenticación).

Los desarrolladores deben implementar la autorización del lado del servidor después de la autenticación correcta antes de conceder permisos de acceso y garantizar que se conceda acceso a los usuarios en función de lo siguiente:

Rol asignado con permisos: Asegúrate de que los usuarios solo pueden realizar tareas relevantes para sus responsabilidades.
Factores contextuales: Escenarios dinámicos de acceso, como la hora de acceso y el análisis del comportamiento.

Implementa la autorización del lado del cliente a través de la vinculación de dispositivos.

La autorización del lado del cliente (es decir, en el dispositivo) es el proceso de gestionar los permisos de acceso dentro de una aplicación móvil. Esto es arriesgado, ya que confiar en la autorización del lado del cliente puede exponer las aplicaciones a vulnerabilidades como el acceso no autorizado y el posible fraude.

Si las funciones de negocio de una aplicación (por ejemplo, instanciar tokens de software) requieren autorizaciones del lado del cliente, se recomienda la vinculación de dispositivos (una práctica de seguridad que asocia autorizaciones a privilegios de acceso en un dispositivo concreto). Mediante la vinculación de dispositivos, las aplicaciones pueden verificar la identidad del dispositivo y establecer la confianza. Esto reduce los riesgos asociados a los accesos no autorizados y mantiene una ruta segura y de confianza entre dispositivos, aplicaciones y servidores. Los desarrolladores deben establecer la vinculación entre las aplicaciones y el dispositivo cuando la identidad de un usuario se utiliza por primera vez en un dispositivo móvil no registrado y también deben verificar que las aplicaciones:

Comprueba si se han producido modificaciones en el dispositivo desde el último tiempo de ejecución.
Compruebe si se han producido modificaciones en los marcadores de identidad del dispositivo.
Comprueba que el dispositivo que ejecuta la aplicación se encuentra en un estado seguro (por ejemplo, sin jailbreaking ni rooting).

Los anteriores son sólo algunos ejemplos de técnicas de buenas prácticas utilizadas por la industria. A medida que evoluciona el ecosistema de dispositivos móviles, estas técnicas pueden quedar obsoletas. Por ello, los desarrolladores deben mantenerse al día de las últimas prácticas recomendadas del sector para verificar los enlaces de los dispositivos.

Para verificar un dispositivo Android, los desarrolladores pueden:

Obtener identificadores únicos como IMEI o Android ID.
Recuperar información de construcción.
Aproveche las funciones nativas de la API del sistema operativo, como SafetyNet de Google.

Para verificar un dispositivo iOS, los desarrolladores pueden:

Aproveche los servicios nativos del sistema operativo, como el ID de dispositivo de Apple, a través de UIDevice.

La aplicación notifica a los usuarios todos los permisos necesarios antes de que empiecen a utilizarla.

Los permisos requeridos son derechos y capacidades específicos que la aplicación solicita al dispositivo móvil. Estos permisos definen a qué recursos o funcionalidades puede acceder la aplicación en los dispositivos de los usuarios. Algunos ejemplos son, entre otros, la cámara, el micrófono, la ubicación, etc.

Mediante la implementación de notificaciones adecuadas que informen a los usuarios de qué permisos se están solicitando, los desarrolladores pueden evitar que los usuarios concedan permisos excesivos sin saberlo, lo que puede permitir a los actores maliciosos explotar vulnerabilidades y robar datos confidenciales (es decir, PII y datos de autenticación). Estas notificaciones también permitirán a los usuarios tomar decisiones informadas sobre las aplicaciones que instalan.

Los promotores deberían:

utilizar alertas In-App (en la aplicación) para solicitar permisos de acceso a los usuarios.
garantizar que las Notificaciones/Alertas no muestren datos sensibles.
sólo solicitan permisos esenciales para el funcionamiento de la aplicación.

La aplicación notifica a los usuarios todas las transacciones de alto riesgo que han sido autorizadas y completadas.

Si una aplicación tiene funcionalidades de transacciones de alto riesgo, los usuarios deben ser notificados inmediatamente cuando una transacción ha sido autorizada y completada. Mediante la aplicación de este control, los desarrolladores pueden garantizar que los usuarios sepan inmediatamente cuándo se han autorizado y completado transacciones de alto riesgo para que puedan identificar
posibles transacciones fraudulentas lo antes posible.

Los desarrolladores deben adoptar los siguientes métodos para alertar a un usuario:

Alertas dentro de la aplicación (In-App).
Notificaciones por correo electrónico.
Notificaciones del Servicio de Mensajes Cortos (SMS).

Los desarrolladores también deben asegurarse de que las notificaciones/alertas no muestren datos confidenciales y sólo soliciten los permisos esenciales para la funcionalidad de la aplicación.

Los anteriores son sólo algunos ejemplos de las mejores técnicas de notificación utilizadas por la industria. A medida que evoluciona el ecosistema de los dispositivos móviles, estas técnicas pueden quedar desfasadas. Por ello, los desarrolladores deben mantenerse al día de las últimas mejores prácticas del sector para notificar a los usuarios las transacciones de alto riesgo autorizadas y completadas.

Almacenamiento de datos

Salvaguardar la integridad y confidencialidad de los datos sensibles en el dispositivo del usuario y en el servidor de aplicaciones.

La aplicación almacena datos confidenciales que sólo son necesarios para las transacciones.

Los datos sensibles se definen como datos de usuario (IPI) y datos de autenticación (por ejemplo, credenciales, claves de cifrado, etc.). Los desarrolladores sólo deben almacenar los datos sensibles que sean necesarios para las funciones empresariales de la aplicación. Acumular información innecesaria aumenta el impacto de posibles brechas de seguridad, convirtiendo una aplicación en un objetivo atractivo para los actores maliciosos.

Al implantar este control de seguridad, los desarrolladores pueden garantizar que la exposición se limita a los datos necesarios para funciones empresariales específicas, minimizando el impacto en caso de acceso no autorizado o violación de datos.

Los desarrolladores deben clasificar los datos que utiliza la aplicación en función de los niveles de sensibilidad de la organización y de los requisitos legales, y adoptar las siguientes directrices para proteger los datos clasificados como sensibles:

Implantar una solución de almacenamiento seguro en función de su sensibilidad en el lado cliente/servidor.
Aplicar medidas de protección de datos (por ejemplo, tokenización, hash con sal, cifrado).
Elimine los datos sensibles cuando ya no sean necesarios.

La aplicación permite el almacenamiento seguro de datos confidenciales.

El almacenamiento seguro de aplicaciones móviles se refiere a la aplicación de técnicas y prácticas para proteger los datos confidenciales almacenados en dispositivos móviles y servidores de aplicaciones contra el acceso no autorizado, el robo o la manipulación. Esto implica buenas prácticas como cifrado, hashing, tokenización y controles de acceso adecuados. Al implementar un almacenamiento seguro, los desarrolladores pueden mitigar el acceso no autorizado, el compromiso del dispositivo, las posibles violaciones de datos y las fugas de datos.

Los desarrolladores deben implementar una solución de almacenamiento seguro que sea proporcional a la sensibilidad de los datos y también deben priorizar el siguiente orden para una solución de almacenamiento seguro (de los datos más sensibles a los menos sensibles):

Del lado del servidor (todos los datos sensibles deben almacenarse del lado del servidor).
Del lado del cliente dentro del Entorno de Ejecución de Confianza (en caso de que no sea posible del lado del servidor, almacene todos los datos sensibles en el TEE del lado del cliente).

La aplicación almacena los datos confidenciales de forma segura en el servidor.

El almacenamiento de datos sensibles en el servidor consiste en almacenar los datos en servidores de aplicaciones o bases de datos remotos. Este enfoque crea un entorno mejor para proteger los datos de accesos no autorizados o infracciones, lo que permite un control de acceso más seguro, opciones para aplicar mejores medidas de seguridad como cifrados más complejos y actualizaciones de seguridad más rápidas.

Al implementar el almacenamiento de datos sensibles en el lado del servidor, los desarrolladores pueden mitigar los riesgos inherentes al almacenamiento de datos en el lado del cliente, ya que el almacenamiento en el lado del cliente es intrínsecamente más susceptible a las técnicas de explotación de almacenamiento de datos utilizadas habitualmente por los actores maliciosos en las estafas móviles.

Los desarrolladores deben aplicar al menos 1 de las siguientes medidas de protección de datos:

Sólo para contraseñas, los desarrolladores pueden utilizar hashing con sal (el hashing con sal se utiliza para añadir una capa extra de seguridad haciendo que sea computacionalmente intensivo para los atacantes
descifrar los datos sensibles originales. En el contexto del almacenamiento de contraseñas o la derivación de claves, los desarrolladores deben utilizar funciones de derivación de claves unidireccionales o algoritmos hash lentos, como PBKDF2, bcrypt o script). En lugar de almacenar contraseñas reales, se generan sales únicas que se combinan con las contraseñas, creando hashes con sal.
Los desarrolladores pueden cifrar datos sensibles con estándares de encriptación como AES-128.
Los desarrolladores pueden implementar la tokenización con una tokenización autogestionada o con un servicio de tokenización, sustituyendo los datos sensibles por tokens siempre que sea posible. Además, los desarrolladores deben asegurarse de que la tokenización sea lo suficientemente larga y compleja (respaldada por una criptografía segura) en función de la sensibilidad de los datos y las necesidades de la empresa.

Los anteriores son sólo algunos ejemplos de buenas prácticas utilizadas por la industria. A medida que evoluciona el ecosistema de los dispositivos móviles, estas buenas prácticas pueden quedar obsoletas. Por ello, los desarrolladores deben estar al día de las últimas buenas prácticas del sector para almacenar datos confidenciales de forma segura en el servidor.

La aplicación almacena los datos confidenciales de forma segura en un entorno de ejecución de confianza (TEE).

El Entorno de Ejecución de Confianza (TEE) es una zona aislada dentro de la arquitectura de hardware o procesador de un dispositivo móvil que proporciona un entorno altamente seguro para almacenar datos sensibles y ejecutar operaciones sensibles o críticas. Está diseñado para proteger datos sensibles, claves criptográficas y procesos críticos frente a accesos no autorizados o manipulaciones. Si las funciones empresariales de una aplicación requieren almacenamiento sensible en el lado del cliente, se recomienda almacenarlo en el TEE del dispositivo.

Al implementar un almacenamiento adecuado de los datos confidenciales en el TEE del lado del cliente, los desarrolladores pueden mitigar las amenazas procedentes de un dispositivo comprometido y de actores maliciosos externos. Dicho almacenamiento también puede mitigar el acceso no autorizado a los datos confidenciales del usuario en una aplicación y evitar que se roben las claves de cifrado.

Los desarrolladores deben almacenar los datos confidenciales de forma segura en el lado del cliente en un entorno de ejecución de confianza (TEE), como TrustZone de ARM de Android y Secure Enclave de Apple. Los desarrolladores también deben almacenar como mínimo la siguiente lista de datos confidenciales en un TEE:

Identificadores biométricos.
Fichas de autenticación.
Claves criptográficas en un sistema seguro de gestión de claves como Android Keystore, iOS Keychain.

Los anteriores son sólo algunos ejemplos de los datos sensibles que los desarrolladores deben almacenar en el TEE. A medida que evoluciona el ecosistema de los dispositivos móviles, los desarrolladores deben ejercer la libertad de almacenar cualquier dato que consideren necesario almacenar en el TEE.

En el caso de los dispositivos sin TEE de hardware, los desarrolladores pueden considerar el uso de TEEs virtualizados. Como alternativa, los desarrolladores pueden considerar desactivar la aplicación o desactivar las funciones de transacciones de alto riesgo de la aplicación, ya que la aplicación se considera insegura para las transacciones de alto riesgo.

La aplicación elimina los datos sensibles cuando ya no son necesarios.

El borrado de datos sensibles hace referencia al proceso de eliminar o borrar permanentemente datos confidenciales, privados o sensibles de dispositivos de almacenamiento, servidores o bases de datos. Este proceso garantiza que los datos sensibles se eliminan de forma irrecuperable y no pueden ser accedidos, recuperados, expuestos accidentalmente o reconstruidos por personas no autorizadas o mediante métodos de recuperación de datos.

Mediante la aplicación de este proceso, los desarrolladores pueden minimizar la ventana en la que los atacantes pueden explotar las vulnerabilidades para robar datos sensibles. Los desarrolladores deben utilizar las siguientes técnicas de seguridad de almacenamiento persistente:

Borre las cookies almacenadas al finalizar la aplicación o utilice el almacenamiento de cookies en memoria.
Elimina todos los datos sensibles al desinstalar la aplicación.
Elimine manualmente del sistema de archivos todos los archivos de base de datos que contengan datos confidenciales (por ejemplo, cachés de iOS WebView) cuando cesen las funciones empresariales relacionadas.

Los anteriores son sólo algunos ejemplos de las mejores prácticas utilizadas por la industria. A medida que evoluciona el ecosistema de los dispositivos móviles, estas técnicas pueden quedar desfasadas. Por ello, los desarrolladores deben estar al tanto de las últimas buenas prácticas del sector para eliminar los datos sensibles cuando ya no sean necesarios.

Antimanipulación y antirretroceso

Implanta medidas para evitar que la aplicación sea manipulada o puesta en peligro. Algunos ejemplos son las funciones antivirus y la protección contra la vigilancia y el espionaje del teclado.

La aplicación está firmada con certificados de tiendas de aplicaciones oficiales.

Las aplicaciones son a menudo falsificadas por agentes maliciosos y distribuidas a través de canales menos estrictamente regulados. Firmar una aplicación con certificados proporcionados por tiendas de aplicaciones oficiales garantiza al sistema operativo móvil y a los usuarios que la aplicación procede de una fuente verificada.

La implementación de la firma de código ayuda a los sistemas operativos a determinar si deben permitir que el software se ejecute o instale en función de las firmas o certificados utilizados para firmar el código. Esto ayuda a evitar la instalación y ejecución de aplicaciones potencialmente dañinas. Además, la firma de código también ayuda a verificar la integridad, ya que las firmas cambiarán si la aplicación ha sido manipulada.

Los desarrolladores deben firmar el código de sus aplicaciones con certificados. Esta sección proporciona ejemplos de cómo hacerlo a través de las dos plataformas más populares, iOS y Android. Puede hacerse para la App Store de Apple inscribiéndose en el Programa para Desarrolladores de Apple y creando una solicitud de firma de certificado
en el portal para desarrolladores. Los desarrolladores pueden inscribirse en el Programa para Desarrolladores de Apple y consultar la siguiente guía para desarrolladores sobre la firma de código en el apartado "Aspectos a tener en cuenta". Para Android, hay varias tiendas de aplicaciones. Para Play Store de Google, se puede hacer mediante la configuración de Play App Signing, que es un requisito para la distribución a través de Play Store de Google.

La aplicación implementa la detección de jailbreak o root.

Los dispositivos rooteados y con jailbreak suelen considerarse inseguros. Los dispositivos rooteados o con jailbreak permiten a los usuarios obtener privilegios elevados, lo que facilita la elusión de las limitaciones de seguridad y del sistema operativo. Estos privilegios elevados pueden ser inseguros para las aplicaciones, ya que permiten a los actores maliciosos explotar vulnerabilidades, robar credenciales, tomar el control de los dispositivos de los usuarios y ejecutar transacciones fraudulentas de aplicaciones.

Mediante la implementación de la detección dejailbreak o root, los desarrolladores pueden evitar que se produzcan los exploits antes mencionados, proteger la propiedad intelectual de las aplicaciones, garantizar la estabilidad de las aplicaciones y evitar el bypass de los sistemas in-app.

Detección de jailbreak o root en Android:

Compruebe si hay superusuario o binario SU.
Detectar cambios en el sistema de archivos raíz.
Busca aplicaciones rooteadas.
Comprueba la recuperación personalizada.
Comprobación de uso inseguro de la API.

Detección de jailbreak o root en iOS:

Detectar el uso de API restringidas.
Busca tweaks de jailbreak como mods.
Busca tiendas de aplicaciones no oficiales, por ejemplo, busca la firma de Cydia App Store.
Busca modificaciones en el núcleo.
Compruebe la integridad de los sistemas de archivos críticos.
Utilice bibliotecas de terceros diseñadas para detectar la manipulación de dispositivos.

La aplicación implementa la detección de emuladores.

Los emuladores son programas utilizados para probar aplicaciones móviles, ya que permiten al usuario probar una aplicación móvil en una variedad de versiones y dispositivos móviles imitados. Aunque son útiles para las pruebas, las aplicaciones no deben montarse en emuladores fuera del entorno de desarrollo.

Al implementar la detección de emulación, los desarrolladores pueden evitar que los actores maliciosos ejecuten análisis dinámicos, rooting, debugging, instrumentación, hooking y fuzz testing en un dispositivo emulado que puedan controlar. Al hacerlo, los desarrolladores pueden evitar que los actores maliciosos descubran vulnerabilidades dentro de la aplicación para su explotación.

Los desarrolladores deben implementar la siguiente estrategia de detección para identificar las características de las soluciones de emulación más utilizadas. Algunas recomendaciones de cosas a comprobar son:

Comprueba el uso de la batería.
Comprueba las marcas de tiempo y los relojes.
Comprueba los comportamientos multitáctiles.
Compruebe la memoria y el análisis de rendimiento.
Realiza comprobaciones en la red.
Comprueba si está basado en hardware.
Comprueba en qué se basa el sistema operativo.
Comprueba las huellas dactilares del dispositivo.
Compruebe las configuraciones de compilación.
Busca servicios y aplicaciones de emulación.

Los anteriores son sólo algunos ejemplos de comprobaciones de buenas prácticas utilizadas por la industria. A medida que evoluciona el ecosistema de dispositivos móviles, estas comprobaciones pueden quedar obsoletas. Por ello, los desarrolladores deben estar al día de las últimas buenas prácticas del sector para implementar la detección de emuladores.

La aplicación incorpora detección antimalware.

Los actores maliciosos utilizan cada vez más las aplicaciones maliciosas como vector para comprometer los dispositivos móviles de los usuarios, ya que estos les proporcionan la comodidad necesaria para realizar transacciones cotidianas. Las aplicaciones maliciosas utilizan principalmente funciones de carga lateral como canal para conseguir que los usuarios instalen programas maliciosos en sus dispositivos.

Al implementar capacidades de detección antimalware en una aplicación en tiempo de ejecución, los desarrolladores pueden evitar que los usuarios sean explotados a través de malware que aproveche las vulnerabilidades de la aplicación y las vulnerabilidades del sistema operativo, robe credenciales, tome el control del dispositivo y ejecute transacciones fraudulentas. Los desarrolladores deben implementar capacidades de detección antimalware en sus aplicaciones. Esto se puede hacer de varias maneras, pero no se limitan a:

Incorporar a sus aplicaciones un kit de desarrollo de software (SDK) de autoprotección de aplicaciones en tiempo de ejecución (RASP).
Utilice los SDK de RASP para comprobar y detectar aplicaciones maliciosas en tiempo de ejecución.
Compruebe y evite los solapamientos.
Evite el clickjacking.
Evitar el enganche de memoria de la aplicación.

Los anteriores son sólo algunos ejemplos de comprobaciones de buenas prácticas utilizadas por la industria. A medida que evoluciona el ecosistema de los dispositivos móviles, estas comprobaciones pueden quedar desfasadas. Por ello, los desarrolladores deben estar al tanto de las últimas buenas prácticas del sector para aplicar la detección antimalware.

Si se detecta algún tipo de malicia, los desarrolladores deben desactivar la aplicación y proporcionar al usuario la información necesaria sobre por qué se ha desactivado la aplicación e instarle a que desinstale la aplicación o aplicaciones maliciosas en su dispositivo. Alternativamente, los desarrolladores deben advertir al usuario y desactivar las funciones de alto riesgo de la aplicación hasta que el usuario corrija la aplicación o aplicaciones maliciosas.

La aplicación implementa mecanismos anti-hooking.

El hooking es una técnica utilizada por los atacantes para interceptar o modificar el comportamiento de una aplicación móvil en tiempo de ejecución. Se trata de insertar o enganchar en el flujo de ejecución de una aplicación para supervisar sus actividades, alterar su comportamiento, inyectar código malicioso o modificar funciones de código existentes para explotar vulnerabilidades.

Mediante la implementación de mecanismos anti-hooking en las aplicaciones, los desarrolladores pueden evitar que se produzcan los ataques mencionados e impedir el acceso no autorizado, proteger las operaciones de transacciones de alto riesgo, detectar e impedir los intentos de manipulación y modificación, preservar la propiedad intelectual y mantener la fiabilidad de la aplicación. Los desarrolladores deben implementar los siguientes mecanismos de ejemplo para mitigar los ataques de hooking:

Implantar protecciones para bloquear las inyecciones de código.
Implementar protecciones para evitar el hooking de métodos impidiendo modificaciones en el código fuente de la app (tanto en el cliente como en el servidor).
Implemente protecciones para evitar la ejecución de códigos modificados en su aplicación.
Implemente protecciones para evitar el acceso a la memoria y la manipulación de la memoria de su aplicación.
Implementar algoritmos resistentes a la manipulación o SDK antimanipulación (conocidos comúnmente como SDK de autoprotección de aplicaciones en tiempo de ejecución).
Compruebe si hay parámetros inseguros, como API y parámetros obsoletos.

La aplicación implementa contramedidas de superposición, visualización remota y captura de pantalla.

La información sensible puede ser capturada o grabada sin el consentimiento explícito del usuario cuando una aplicación tiene funcionalidades de grabación, captura o superposición de pantalla. Por ejemplo:

Los ataques de superposición engañan a los usuarios creando una capa falsa que imita a las aplicaciones de confianza, con el objetivo de robar datos confidenciales.
Los ataques de visualización remota implican el acceso no autorizado a la pantalla de un dispositivo, lo que permite a los atacantes recopilar datos confidenciales de forma remota.
Los ataques de captura de pantalla se producen cuando actores maliciosos capturan la pantalla de un dispositivo sin el consentimiento del usuario, extrayendo datos sensibles.

La aplicación de contramedidas de superposición, visualización remota y captura de pantalla puede garantizar que la información confidencial permanezca segura, que se respete la privacidad del usuario y que los datos confidenciales estén protegidos frente a pérdidas involuntarias o usos indebidos.

Los desarrolladores deben implementar controles antimanipulación y antimalware a través de los SDK de RASP para evitar que las aplicaciones maliciosas utilicen superposiciones y exploits de visión remota.

En el caso de las capturas de pantalla, los desarrolladores pueden utilizar la bandera FLAG_SECURE para aplicaciones Android y banderas similares para iOS para bloquear todas las capacidades de captura de pantalla durante el uso de la aplicación. Sin embargo, supongamos que las funciones empresariales requieren capacidades de captura de pantalla (por ejemplo, hacer una captura de pantalla de una transacción bancaria completada). En ese caso, la recomendación es desactivar las capacidades de captura de pantalla para pantallas o páginas que incluyan datos sensibles (PII y datos de autenticación). Los desarrolladores también pueden considerar la posibilidad de enmascarar las entradas con datos sensibles y las pantallas de sensores cuando la aplicación está en segundo plano.

Algunos ejemplos de dónde desactivar estas capacidades de captura de pantalla incluyen, pero no se limitan a, páginas de inicio de sesión, páginas de autenticación multifactor, credenciales de seguridad y páginas de cambio de PII, etc.

La aplicación implementa captura anti-keystroke o anti-keylogger contra teclados virtuales de terceros en dispositivos Android.

La captura y el registro de pulsaciones de teclas son métodos que utilizan los actores maliciosos para vigilar, registrar y grabar las teclas pulsadas en un teclado sin el conocimiento ni el consentimiento del usuario. Esto permite el registro y la captura de datos potencialmente sensibles (es decir, PII y datos de autenticación).

Al implementar un teclado en la aplicación, los desarrolladores pueden controlar adónde van los datos de registro y mitigar el riesgo de que teclados virtuales inseguros de terceros actúen como keyloggers para capturar las pulsaciones.

Además de utilizar teclados integrados en las aplicaciones, los desarrolladores deberían aplicar las siguientes sugerencias para las entradas que requieran datos sensibles (es decir, PII y datos de autenticación): Desactivar las funciones de autocorrección, autorrelleno, autosugestión, cortar, copiar y pegar para las funciones o aplicaciones que contengan datos sensibles. Algunos ejemplos de funciones que deberían utilizar teclados integrados en la aplicación son, entre otros, iniciar sesión, introducir una contraseña de usuario (OTP) u otros factores de verificación, etc.