Mejores prácticas de aplicaciones seguras para una mejor 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 para la seguridad del desarrollador, 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 cuatro á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 tres 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. Las plataformas IOS y 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 o 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.
La 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.
Mejora 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 segura sin estado implica prácticas de token seguras para una autenticación eficaz y escalable.
autenticación. 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.
La autenticación sin estado garantiza que cada token se gestiona de forma segura al tiempo que se obtienen ventajas de eficiencia y 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.
Criptográficamente, firmar los tokens utilizando un algoritmo seguro, evitando utilizar 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 la sesión cierra efectivamente las sesiones de usuario. Los actores maliciosos pueden explotar puntos de acceso persistentes si las sesiones no se gestionan adecuadamente en situaciones como el cierre de sesión, la inactividad o el cierre de aplicaciones.
La implementación de la finalización segura de la sesión 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:
Reautenticar 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.
El servidor genera nuevos identificadores de sesión para evitar la fijación de sesión cada vez que los usuarios alcanzan un nuevo nivel de autenticación.
Asegúrese de que la finalización de la sesión incluye la eliminación o desautorización de todos los tokens o identificadores de sesión almacenados localmente.
Determine 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.
Ten en cuenta que todos los mecanismos de MFA son vulnerables a la fuerza bruta, y es esencial transmitir las razones del bloqueo de la cuenta y proporcionar medios accesibles para que los usuarios se autentiquen y eliminen el bloqueo. Algunos ejemplos son llamar a
o mediante 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.
Implantar 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 (por ejemplo, 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.
Implantar la autorización del lado del cliente mediante la vinculación de dispositivos.
La autorización del lado del cliente (es decir, en el dispositivo) gestiona 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 es 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 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 y la ubicación.
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 (por ejemplo, IPI 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:
Utiliza alertas in-app para solicitar permiso de acceso a los usuarios.
Asegúrese de que las Notificaciones/Alertas no muestren datos sensibles.
Solicite únicamente los permisos esenciales para el funcionamiento de la aplicación.
La aplicación notifica a los usuarios todas las transacciones de alto riesgo 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, de modo 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 el sector. A medida que evoluciona el ecosistema de los dispositivos móviles, estas técnicas pueden quedar obsoletas. 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 (PII) y datos de autenticación (por ejemplo, credenciales, claves de cifrado). Los desarrolladores solo 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 de accesos no autorizados o violaciones 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 implantar un almacenamiento seguro, los desarrolladores pueden mitigar los riesgos de acceso no autorizado, compromiso del dispositivo y posibles fugas y violaciones 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 (cuando sea imposible 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 se refiere al almacenamiento de datos en servidores de aplicaciones o bases de datos remotas. 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 un cifrado más complejo, y disposiciones para 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:
Para las contraseñas únicamente, los desarrolladores pueden utilizar hashing con sal (el hashing con sal se utiliza para añadir una capa adicional de seguridad haciendo que sea computacionalmente intensivo para los atacantes
Para descifrar 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 las mejores prácticas del sector. A medida que evoluciona el ecosistema de los dispositivos móviles, estas mejores 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 datos confidenciales de forma segura en el lado del cliente 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. Protege los datos sensibles, las claves criptográficas y los 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, debe almacenarse en el TEE del dispositivo.
Los desarrolladores pueden mitigar las amenazas procedentes de un dispositivo comprometido y de actores maliciosos externos almacenando adecuadamente los datos confidenciales en el TEE del lado del cliente. Este almacenamiento también puede reducir el acceso no autorizado a los datos confidenciales de un usuario en una aplicación y evitar que se roben las claves de cifrado.
Los desarrolladores deben almacenar los datos confidenciales del lado del cliente de forma segura en un Entorno de Ejecución de Confianza (TEE) como ARM TrustZone 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 o iOS Keychain.
Los ejemplos anteriores son datos sensibles que los desarrolladores deberían almacenar en el TEE. A medida que evoluciona el ecosistema de los dispositivos móviles, los desarrolladores deben poder almacenar cualquier dato necesario en el TEE.
Los desarrolladores pueden considerar el uso de TEEs virtualizados para dispositivos sin TEEs de hardware. Como alternativa, los desarrolladores pueden desactivar la app o sus funciones de transacciones de alto riesgo, ya que la app se considera insegura para transacciones de alto riesgo.
La aplicación elimina los datos sensibles cuando ya no son necesarios.
Borrar datos sensibles significa 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.
Cuando cesen las funciones empresariales relacionadas, elimine manualmente del sistema de archivos todos los archivos de base de datos que contengan datos confidenciales (por ejemplo, cachés de iOS WebView).
Los anteriores son sólo algunos ejemplos de las mejores prácticas del sector. A medida que evoluciona el ecosistema de los dispositivos móviles, estas técnicas pueden quedar obsoletas. Por ello, los desarrolladores deben estar al día de las últimas buenas prácticas del sector para eliminar datos confidenciales cuando ya no sean necesarios.
Antimanipulación y antirretroceso
Implementa 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 está 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 cambian si la aplicación ha sido manipulada.
Los desarrolladores deben firmar el código de sus aplicaciones con certificados. Esta sección ofrece ejemplos de cómo hacerlo a través de las dos plataformas más populares, iOS y Android. Para la App Store de Apple, puede inscribirse en el Programa para Desarrolladores de Apple y crear un
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 la sección "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. 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 de jailbreak o root, los desarrolladores pueden evitar que se produzcan los exploits mencionados, proteger la propiedad intelectual de las aplicaciones, garantizar la estabilidad de las mismas e impedir que se eludan los sistemas integrados en ellas.
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 no seguro 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.
Los anteriores son sólo algunos ejemplos de comprobaciones de buenas prácticas utilizadas por el sector. A medida que evoluciona el ecosistema de los 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 jailbreak o root.
La aplicación implementa la detección de emuladores.
Los emuladores son programas utilizados para probar aplicaciones móviles. Permiten a los usuarios probar una aplicación móvil en varias versiones y dispositivos imitados. Aunque son útiles para las pruebas, las aplicaciones no deben instalarse en emuladores fuera del entorno de desarrollo.
Al implementar la detección por 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. De este modo, los desarrolladores pueden evitar que los actores maliciosos descubran vulnerabilidades en la aplicación para explotarlas.
Los desarrolladores deben aplicar 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 si hay 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 el sector. 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 de malware como vector para comprometer los dispositivos móviles de los usuarios. Estas aplicaciones ofrecen a los usuarios la comodidad necesaria para realizar transacciones cotidianas. Las aplicaciones de malware utilizan principalmente funciones de carga lateral para conseguir que los usuarios instalen malware 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 el sector. A medida que evoluciona el ecosistema de los dispositivos móviles, estas comprobaciones pueden quedar obsoletas. Por ello, los desarrolladores deben estar al día de las últimas mejores prácticas del sector para implementar la detección antimalware.
Si se detecta algún tipo de malicia, los desarrolladores deben desactivar la aplicación, proporcionar al usuario la información necesaria sobre el motivo de la desactivación e instarle a desinstalar la aplicación o aplicaciones maliciosas de 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.
Los anteriores son sólo algunos ejemplos de comprobaciones de buenas prácticas utilizadas por el sector. A medida que evoluciona el ecosistema de los 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 implantar mecanismos antienganche.
La aplicación implementa contramedidas de superposición, visualización remota y captura de pantalla.
Se puede capturar o grabar información sensible sin el consentimiento explícito del usuario cuando una aplicación tiene funciones 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 y extraen datos confidenciales.
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 de negocio requieren capacidades de captura de pantalla (por ejemplo, tomar 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 deshabilitar 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.
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 (por ejemplo, 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 (por ejemplo, PII y datos de autenticación): Desactivar las funciones de autocorrección, autorrelleno, autosugestión, cortar, copiar y pegar para funciones o aplicaciones que contengan datos sensibles. Algunas tareas que deberían utilizar los teclados de las aplicaciones son el inicio de sesión, la introducción de un OTP u otros factores de verificación.