OWASP Mobile Top 10 2024

OWASP Mobile Top 10 es una lista compilada por la Open Web Application Security Project (OWASP), una comunidad de seguridad sin fines de lucro que se enfoca en mejorar la seguridad del software. Esta lista identifica y describe las diez vulnerabilidades más críticas y comunes que afectan a las aplicaciones móviles. El propósito del OWASP Mobile Top 10 es aumentar la conciencia sobre las amenazas de seguridad móvil y proporcionar orientación a desarrolladores, profesionales de seguridad y organizaciones para mitigar estos riesgos.

Cada vulnerabilidad en la lista es detallada con una descripción, indicadores que pueden indicar su presencia, recomendaciones de mitigación y ejemplos de ataques relacionados. Estas vulnerabilidades cubren una amplia gama de problemas de seguridad que van desde la mala autenticación y autorización, hasta el almacenamiento inseguro de datos y la insuficiente protección criptográfica. El OWASP Mobile Top 10 ha sido actualizado en 2024, después de 8 años y refleja las últimas tendencias y desafíos en el campo de la seguridad móvil, proporcionando así una guía valiosa para la comunidad de desarrollo de aplicaciones.

Vulnerabilidad M1: Improper Credential Usage

La vulnerabilidad M1, "Improper Credential Usage" (Uso inapropiado de credenciales), se refiere a prácticas inadecuadas relacionadas con la gestión y almacenamiento de credenciales en aplicaciones móviles. Esta vulnerabilidad puede surgir cuando las credenciales (como nombres de usuario, contraseñas, tokens de autenticación, etc.) no se manejan de manera segura, exponiéndolas a posibles atacantes.

Indicadores de riesgo

 • Almacenamiento inseguro: Las credenciales se almacenan en texto plano en el sistema de archivos del dispositivo, en bases de datos no cifradas o en preferencias compartidas sin protección.

 • Transmisión insegura: Las credenciales se envían a través de la red sin cifrar (por ejemplo, utilizando HTTP en lugar de HTTPS).

 • Manejo inadecuado de sesiones: No se invalidan las sesiones correctamente al cerrar sesión, permitiendo que un atacante reutilice tokens de sesión.

 • Uso de mecanismos de autenticación obsoletos: Empleo de algoritmos de cifrado débiles o métodos de autenticación que han sido comprometidos.

Mitigaciones recomendadas

 • Utilizar el almacenamiento seguro proporcionado por el sistema operativo (por ejemplo, Keychain en iOS, Keystore en Android).
 • Evitar almacenar credenciales en texto plano o en ubicaciones no seguras.
 • Cifrar todas las comunicaciones que contengan credenciales utilizando TLS/SSL.
 • Implementar HTTPS con configuraciones seguras y certificados válidos.
 • Invalidar tokens de sesión al cerrar sesión.
 • Utilizar tokens de sesión con tiempos de expiración y revocación apropiados.
 • Implementar mecanismos de renovación de tokens seguros.
 • Utilizar autenticación multifactor (MFA) cuando sea posible.
 • Emplear algoritmos de cifrado y hash fuertes y actualizados.
 • No reutilizar credenciales en diferentes servicios o aplicaciones.


Ejemplos de ataques

Almacenamiento inseguro:

Un atacante con acceso físico al dispositivo o mediante un exploit puede acceder a un archivo de texto plano que contiene credenciales almacenadas sin cifrar, obteniendo así acceso no autorizado a la aplicación o a los servicios asociados.

Intercepción de tráfico:

Si una aplicación transmite credenciales a través de HTTP, un atacante que pueda interceptar el tráfico de red (por ejemplo, mediante un ataque man-in-the-middle) puede capturar las credenciales y usarlas para acceder a la aplicación.

Secuestro de sesión:

Si los tokens de sesión no se invalidan adecuadamente al cerrar sesión, un atacante que obtenga un token válido (por ejemplo, a través de un ataque XSS) puede reutilizarlo para acceder a la sesión del usuario sin necesidad de conocer sus credenciales.

Autenticación obsoleta:

Utilizar algoritmos de hash débiles como MD5 para almacenar contraseñas puede permitir a un atacante que obtenga la base de datos de contraseñas descifrar las contraseñas con relativa facilidad utilizando ataques de fuerza bruta o diccionario.

Vulnerabilidad M2: Inadequate Supply Chain Security

La vulnerabilidad M2, "Inadequate Supply Chain Security" (Seguridad inadecuada en la cadena de suministro), se refiere a los riesgos asociados con la cadena de suministro de software en el desarrollo de aplicaciones móviles. Esto incluye el uso de componentes de terceros, bibliotecas, frameworks y servicios externos que no están adecuadamente verificados o mantenidos. La seguridad de una aplicación puede verse comprometida si cualquiera de estos elementos contiene vulnerabilidades, se ve comprometido o se incluye intencionalmente código malicioso.

Indicadores de riesgo

 • Uso de bibliotecas obsoletas o no mantenidas: Integración de componentes de software que no reciben actualizaciones de seguridad regulares.

 • Falta de verificación de componentes: No se realizan verificaciones adecuadas de la integridad y autenticidad de los componentes de terceros utilizados.

 • Ausencia de monitoreo continuo: No se monitorean activamente las vulnerabilidades de los componentes externos utilizados en la aplicación.

 • Inexistencia de políticas de seguridad: Falta de políticas y procedimientos claros para evaluar y gestionar los riesgos de la cadena de suministro de software.


Mitigaciones recomendadas

 • Utilizar firmas digitales y hashes para verificar la integridad y autenticidad de los componentes de software.

 • Descargar componentes solo de fuentes confiables y verificadas.

 • Mantener actualizados todos los componentes de terceros utilizados en la aplicación.

 • Monitorizar regularmente las bases de datos de vulnerabilidades (como la NVD) para detectar problemas conocidos en los componentes utilizados.

 • Realizar evaluaciones de seguridad y pruebas de penetración periódicas para identificar vulnerabilidades en los componentes de terceros.

 • Establecer un proceso de evaluación y aprobación para la integración de nuevos componentes.

 • Implementar políticas de seguridad claras que aborden la selección, evaluación y uso de componentes de terceros.

 • Fomentar una cultura de seguridad que valore la importancia de una cadena de suministro segura.


Ejemplos de ataques

Inyección de código malicioso en bibliotecas:

Un atacante compromete una biblioteca popular utilizada por muchos desarrolladores. Las aplicaciones que integran esta biblioteca sin verificar su integridad pueden incluir código malicioso que permita al atacante ejecutar código arbitrario en los dispositivos de los usuarios.

Uso de componentes vulnerables:

Una aplicación utiliza una versión obsoleta de una biblioteca de cifrado que tiene una vulnerabilidad conocida. Un atacante puede explotar esta vulnerabilidad para descifrar datos sensibles transmitidos o almacenados por la aplicación.

Ataques a la cadena de suministro:

Un proveedor de software de terceros es comprometido, y el atacante inyecta malware en una actualización de software. Los desarrolladores que integran esta actualización sin realizar verificaciones adecuadas pueden distribuir inadvertidamente malware a los usuarios finales.

Dependencias no verificadas:

Un desarrollador incluye una biblioteca de código abierto sin verificar su origen o historial de seguridad. La biblioteca contiene una puerta trasera que permite a un atacante acceder remotamente a la aplicación y a los datos del usuario.

Vulnerabilidad M3: Insecure Authentication/Authorization

La vulnerabilidad M3, "Insecure Authentication/Authorization" (Autenticación/Autorización Insegura), se refiere a fallas en los mecanismos de autenticación y autorización de una aplicación móvil. Esto incluye cualquier debilidad en cómo los usuarios se autentican en la aplicación y cómo se manejan sus permisos y accesos a diferentes recursos dentro de la aplicación. Las deficiencias en estos mecanismos pueden permitir a atacantes suplantar identidades, obtener acceso no autorizado a recursos y datos, o escalar privilegios.

Indicadores de riesgo

 • Tokens de sesión que no expiran o no se invalidan adecuadamente al cerrar sesión.
 • Sesiones que no se cierran automáticamente después de un período de inactividad.
 • Uso de contraseñas fáciles de adivinar o sin requisitos mínimos de seguridad.
 • Ausencia de autenticación multifactor (MFA).
 • No limitar el número de intentos fallidos de inicio de sesión.
 • Transmisión de credenciales sin cifrar.
 • Almacenamiento de credenciales en texto plano en el dispositivo.
 • Falta de control adecuado de acceso a recursos y funcionalidades.
 • Usuarios que pueden escalar privilegios debido a controles insuficientes.


Mitigaciones recomendadas

 • Implementar autenticación multifactor (MFA) para añadir una capa extra de seguridad.

 • Requerir contraseñas fuertes y aplicar políticas de cambio periódico de contraseñas.

 • Limitar el número de intentos fallidos de inicio de sesión y bloquear cuentas temporalmente después de varios intentos fallidos.

 • Utilizar tokens de sesión seguros y configurarlos para que expiren después de un período de inactividad.

 • Asegurarse de que los tokens de sesión se invaliden adecuadamente al cerrar sesión.

 • Implementar cookies seguras con flags HttpOnly y Secure para proteger los tokens de sesión.

 • Cifrar las credenciales durante la transmisión utilizando HTTPS.

 • Utilizar el almacenamiento seguro del sistema operativo (Keychain en iOS, Keystore en Android) para guardar credenciales.

 • Implementar controles de acceso granulares basados en roles y permisos.

 • Realizar verificaciones de autorización en el servidor para todas las operaciones sensibles.

 • Evitar confiar únicamente en los controles de autorización del lado del cliente.


Ejemplos de ataques

Fuerza bruta:

Un atacante intenta iniciar sesión en la aplicación con múltiples combinaciones de nombre de usuario y contraseña, aprovechando la falta de limitación de intentos de inicio de sesión. Si la aplicación no tiene protección contra fuerza bruta, el atacante eventualmente puede adivinar las credenciales correctas.

Secuestro de sesión:

Si una aplicación no invalida adecuadamente los tokens de sesión al cerrar sesión, un atacante que obtenga un token de sesión válido (por ejemplo, a través de un ataque XSS) puede reutilizarlo para acceder a la cuenta del usuario.

Escalada de privilegios:

Un atacante con acceso a una cuenta de usuario normal puede explotar fallas en los controles de autorización para obtener acceso a funcionalidades o datos reservados para administradores o usuarios con privilegios más altos.

Phishing y ataques de intermediario (Man-in-the-Middle):

Si las credenciales se transmiten sin cifrar, un atacante puede interceptar las comunicaciones y capturar las credenciales utilizando un ataque de intermediario (Man-in-the-Middle). También puede engañar a los usuarios para que ingresen sus credenciales en un sitio web falso mediante técnicas de phishing.

Vulnerabilidad M4: Insufficient Input/Output Validation

La vulnerabilidad M4, "Insufficient Input/Output Validation" (Validación Insuficiente de Entrada/Salida), se refiere a la falta de validación adecuada de los datos que se reciben y envían en una aplicación móvil. Esto incluye no validar o sanitizar adecuadamente los datos de entrada del usuario, respuestas de la API, datos recibidos de otras aplicaciones, o datos almacenados y procesados internamente. La validación insuficiente puede permitir a los atacantes inyectar datos maliciosos, manipular el comportamiento de la aplicación y acceder a datos sensibles.

Indicadores de riesgo

 • Campos de formulario que aceptan cualquier tipo de dato sin restricciones.

 • No se realizan comprobaciones de límites, formatos, tipos de datos o caracteres permitidos en los datos ingresados por el usuario.

 • Datos enviados al navegador o a otras aplicaciones sin ser sanitizados, lo que puede permitir la inyección de scripts o comandos maliciosos.

 • Respuestas de API que no son validadas antes de ser procesadas por la aplicación.

 • Datos que se muestran al usuario sin ser filtrados o sanitizados.

 • Falta de validación en interacciones entre aplicaciones.

 • Datos recibidos de otras aplicaciones que no se validan antes de ser utilizados.


Mitigaciones recomendadas

 • Implementar validaciones robustas del lado del cliente y del servidor para todos los datos ingresados por el usuario.

 • Utilizar listas blancas (whitelists) para definir los formatos y tipos de datos permitidos.

 • Verificar límites, rangos y tamaños de los datos ingresados.

 • Utilizar bibliotecas y funciones seguras para validar los datos de entrada.

 • Sanitizar todos los datos antes de mostrarlos al usuario o enviarlos a otras aplicaciones.

 • Escapar correctamente caracteres especiales para evitar inyecciones de scripts o comandos.

 • Validar y sanitizar las respuestas recibidas de APIs antes de procesarlas o mostrarlas al usuario.

 • Implementar controles de seguridad adicionales para las interacciones con APIs externas.

 • Validar los datos recibidos de otras aplicaciones antes de utilizarlos.

 • Establecer protocolos de comunicación seguros y validar la autenticidad de las fuentes de datos.


Ejemplos de ataques

Inyección SQL:

Si una aplicación no valida adecuadamente los datos de entrada y permite que un usuario ingrese datos maliciosos en un campo de formulario, un atacante puede ejecutar comandos SQL no autorizados que comprometan la base de datos.

Cross-Site Scripting (XSS):

Si una aplicación muestra datos ingresados por el usuario sin sanitizarlos, un atacante puede inyectar scripts maliciosos que se ejecuten en el navegador del usuario, permitiendo el robo de cookies, credenciales y otros datos sensibles.

Inyección de comandos:

Si una aplicación móvil permite que los datos de entrada se pasen directamente a la línea de comandos del sistema operativo sin validación, un atacante puede ejecutar comandos arbitrarios en el dispositivo.

Manipulación de datos de API:

Si una aplicación no valida las respuestas de una API externa antes de procesarlas, un atacante que controle la API o intercepte las comunicaciones puede enviar datos maliciosos que alteren el comportamiento de la aplicación o expongan datos sensibles.


Vulnerabilidad M5: Insecure Communication

La vulnerabilidad M5, "Insecure Communication" (Comunicación Insegura), se refiere a la falta de protección adecuada de los datos transmitidos entre la aplicación móvil y sus servidores backend o entre la aplicación y otros servicios. Esta falta de protección puede permitir a los atacantes interceptar, modificar o espiar los datos transmitidos. Las comunicaciones inseguras pueden exponer datos sensibles, como credenciales de usuario, información personal, o datos financieros, a potenciales atacantes.

Indicadores de riesgo

 • Transmisión de datos a través de HTTP en lugar de HTTPS.

 • Uso de versiones obsoletas y vulnerables de protocolos de seguridad (por ejemplo, SSL 2.0/3.0, TLS 1.0/1.1).

 • No validar adecuadamente los certificados SSL/TLS.

 • Uso de certificados autofirmados sin mecanismos de validación adecuados.

 • Enviar o recibir datos sensibles sin cifrado.

 • Almacenamiento temporal de datos en texto plano durante la transmisión.

 • No implementar medidas para detectar y prevenir ataques Man-in-the-Middle.

 • No utilizar mecanismos de aseguramiento de la identidad del servidor y del cliente.


Mitigaciones recomendadas

 • Utilizar HTTPS en lugar de HTTP para todas las comunicaciones.

 • Implementar versiones modernas y seguras de TLS (como TLS 1.2 o TLS 1.3).

 • Validar adecuadamente los certificados SSL/TLS del servidor.

 • Utilizar certificados emitidos por autoridades de certificación confiables.

 • Implementar pinning de certificados para asegurar que la aplicación solo se comunique con servidores de confianza.

 • Cifrar todos los datos sensibles tanto en tránsito como en reposo.

 • Utilizar algoritmos de cifrado fuertes y actualizados (como AES con un tamaño de clave adecuado).

 • Implementar detección de cambios en certificados y alertas sobre posibles ataques Man-in-the-Middle.

 • Utilizar técnicas como HSTS (HTTP Strict Transport Security) para forzar el uso de HTTPS.

 • Implementar autenticación mutua (client-side certificates) para asegurar que tanto el cliente como el servidor puedan verificar la identidad del otro.


Ejemplos de ataques

Intercepción de tráfico (sniffing):

Un atacante puede utilizar herramientas como Wireshark para interceptar tráfico HTTP no cifrado y obtener información sensible como nombres de usuario, contraseñas o datos personales.

Ataques Man-in-the-Middle:

Un atacante puede interceptar la comunicación entre la aplicación móvil y el servidor, presentando un certificado SSL falso. Si la aplicación no valida correctamente los certificados, el atacante puede descifrar y modificar el tráfico a voluntad.

Ataques de downgrade:

Un atacante puede forzar a la aplicación a utilizar versiones más antiguas y vulnerables de protocolos de seguridad (como SSL 3.0), exponiendo la comunicación a vulnerabilidades conocidas.
Inyección de contenido malicioso:
Si la comunicación no está cifrada, un atacante puede modificar los datos en tránsito, inyectando comandos maliciosos, scripts o redirigiendo a los usuarios a sitios de phishing.


Vulnerabilidad M6: Inadequate Privacy Controls

La vulnerabilidad M6, "Inadequate Privacy Controls" (Controles de Privacidad Inadecuados), se refiere a la falta de medidas adecuadas para proteger la privacidad de los datos personales de los usuarios en aplicaciones móviles. Esto puede incluir la recopilación excesiva de datos, el almacenamiento inseguro de datos personales, la falta de consentimiento adecuado y la falta de transparencia sobre cómo se manejan y comparten los datos. Esta vulnerabilidad puede llevar a violaciones de privacidad, exposición de datos sensibles y posibles problemas legales.

Indicadores de riesgo

 • La aplicación solicita permisos para acceder a más información de la necesaria para su funcionamiento.

 • Recopilación de datos sensibles sin una justificación clara o necesidad funcional.

 • No se solicita el consentimiento explícito del usuario antes de recopilar y procesar sus datos personales.

 • Términos de servicio y políticas de privacidad poco claros o difíciles de entender.

 • Almacenamiento de datos personales sin cifrado.

 • Transmisión de datos personales sin utilizar conexiones seguras (como HTTPS).

 • Los usuarios no pueden acceder, modificar o eliminar sus datos personales.

 • Falta de opciones para que los usuarios limiten la recopilación de datos.

 • Datos personales compartidos con terceros sin informar adecuadamente a los usuarios.

 • No se especifica con quién se comparten los datos y con qué propósito.

Mitigaciones recomendadas

 • Recopilar solo los datos necesarios para el funcionamiento de la aplicación.

 • Evaluar y justificar cada solicitud de permiso o recopilación de datos sensibles.

 • Solicitar el consentimiento explícito y específico de los usuarios antes de recopilar y procesar sus datos personales.

 • Proporcionar términos de servicio y políticas de privacidad claros, accesibles y fáciles de entender.

 • Cifrar los datos personales tanto en reposo como en tránsito.

 • Utilizar conexiones seguras (como HTTPS) para la transmisión de datos.

 • Proporcionar a los usuarios opciones para acceder, modificar y eliminar sus datos personales.

 • Implementar controles de privacidad que permitan a los usuarios limitar la recopilación y uso de sus datos.

 • Informar claramente a los usuarios sobre qué datos se recopilan, cómo se utilizan y con quién se comparten.

 • Establecer y comunicar políticas claras sobre la compartición de datos con terceros.


Ejemplos de ataques

Exposición de datos sensibles:

Una aplicación que almacena datos personales sin cifrado puede ser explotada por un atacante que obtenga acceso al dispositivo o a la base de datos, exponiendo información sensible como nombres, direcciones, números de teléfono, etc.

Falta de consentimiento informado:

Una aplicación que recopila datos de ubicación en segundo plano sin el consentimiento explícito del usuario puede estar violando la privacidad del usuario, permitiendo potencialmente el rastreo y vigilancia no autorizada.

Intercepción de datos personales:

Si una aplicación transmite datos personales a través de una conexión no segura (HTTP en lugar de HTTPS), un atacante que intercepte el tráfico puede capturar información sensible, como credenciales de inicio de sesión, datos financieros, etc.

Datos indebidamente compartidos:

Una aplicación que comparte datos personales con terceros sin informar adecuadamente a los usuarios puede llevar a la explotación de esos datos por parte de anunciantes, brokers de datos o incluso actores maliciosos, comprometiendo la privacidad del usuario.


Vulnerabilidad M7: Insufficient Binary Protections

La vulnerabilidad M7, "Insufficient Binary Protections" (Protecciones Binarias Insuficientes), se refiere a la falta de medidas adecuadas para proteger el código binario de una aplicación móvil contra el análisis, manipulación e ingeniería inversa. Estas protecciones son cruciales para impedir que los atacantes obtengan información sensible, descubran vulnerabilidades en la aplicación o modifiquen su comportamiento para realizar actividades maliciosas.

Indicadores de riesgo

 • El código binario no está ofuscado, lo que facilita el análisis y la ingeniería inversa.

 • No se implementan verificaciones de integridad para detectar modificaciones no autorizadas del código de la aplicación.

 • Herramientas y configuraciones de depuración no deshabilitadas en la versión de producción de la aplicación.

 • No se utilizan técnicas para dificultar el uso de herramientas de análisis y decompilación.

 • Información sensible, como claves de cifrado y credenciales, almacenada directamente en el código binario.

Mitigaciones recomendadas

 • Utilizar herramientas de ofuscación para hacer que el código binario sea más difícil de entender y analizar.

 • Ofuscar tanto el código nativo como el código Java/Kotlin en aplicaciones Android, y Swift/Objective-C en aplicaciones iOS.

 • Implementar verificaciones de integridad en tiempo de ejecución para detectar y responder a modificaciones no autorizadas del código.

 • Utilizar hashes y firmas digitales para verificar la integridad de los binarios.

 • Asegurarse de que las opciones de depuración y las herramientas de desarrollo estén deshabilitadas en las versiones de producción de la aplicación.

 • Utilizar técnicas como anti-debugging para detectar y prevenir el uso de depuradores en la aplicación.

 • Utilizar técnicas para dificultar el uso de herramientas de análisis y descompilación, como empaquetar código nativo y utilizar entornos de ejecución seguros.

 • Implementar detección de emuladores y entornos de análisis estáticos.

 • Evitar almacenar claves de cifrado, credenciales y otra información sensible directamente en el código binario.

 • Utilizar el almacenamiento seguro proporcionado por el sistema operativo (Keychain en iOS, Keystore en Android) para manejar información sensible.


Ejemplos de ataques

Ingeniería inversa:

Un atacante utiliza herramientas como Apktool para descompilar una aplicación Android y analizar su código. Sin protecciones adecuadas, el atacante puede identificar vulnerabilidades, extraer información sensible o modificar el comportamiento de la aplicación para su propio beneficio.

Modificación de binarios:

Un atacante modifica el código binario de una aplicación para eliminar funciones de seguridad, como las comprobaciones de autenticación, y redistribuir la aplicación modificada. Esto puede permitir el uso no autorizado de la aplicación o la explotación de vulnerabilidades.

Extracción de claves de cifrado:

Un atacante analiza el código binario de una aplicación para extraer claves de cifrado almacenadas en texto plano. Con estas claves, el atacante puede descifrar datos sensibles, comprometiendo la privacidad y seguridad del usuario.

Uso de herramientas de depuración:

Si una aplicación no deshabilita las opciones de depuración en la versión de producción, un atacante puede utilizar herramientas de depuración para interceptar y modificar el flujo de ejecución de la aplicación, permitiendo la explotación de vulnerabilidades o la manipulación de datos.


Vulnerabilidad M8: Security Misconfiguration

La vulnerabilidad M8, "Security Misconfiguration" (Mala Configuración de Seguridad), se refiere a la incorrecta configuración de los componentes de seguridad en una aplicación móvil o su entorno. Esto puede incluir configuraciones predeterminadas inseguras, permisos excesivos, opciones de depuración habilitadas en producción, y errores en la configuración de servidores backend. Las malas configuraciones pueden permitir a los atacantes explotar debilidades en la aplicación, accediendo a datos sensibles o comprometiendo su funcionamiento.

Indicadores de riesgo

 • Uso de configuraciones predeterminadas que no están seguras por defecto.

 • No cambiar las contraseñas predeterminadas de bases de datos, servidores o servicios.

 • La aplicación solicita más permisos de los necesarios para su funcionamiento.

 • No se aplica el principio de menor privilegio en las configuraciones de acceso.

 • Opciones de depuración o logs detallados habilitados en la versión de producción.

 • Exposición de información sensible a través de logs o mensajes de error detallados.

 • Servidores backend configurados sin HTTPS.

 • Faltan configuraciones de seguridad como Content Security Policy (CSP) o protección contra ataques XSS.

 • No mantener actualizados los componentes de la aplicación y el servidor.

 • Uso de versiones obsoletas y vulnerables de bibliotecas o frameworks.


Mitigaciones recomendadas

 • Revisar y asegurar todas las configuraciones predeterminadas antes de desplegar la aplicación.

 • Cambiar contraseñas predeterminadas y asegurar configuraciones de acceso a servicios.

 • Solicitar solo los permisos estrictamente necesarios para el funcionamiento de la aplicación.

 • Aplicar el principio de menor privilegio en todas las configuraciones de acceso.

 • Asegurarse de que las opciones de depuración y logs detallados estén deshabilitados en la versión de producción.

 • Utilizar logs adecuados que no expongan información sensible.

 • Utilizar HTTPS para todas las comunicaciones entre la aplicación y los servidores.

 • Implementar políticas de seguridad como CSP, protección contra XSS, y validación de entradas.

 • Aplicar actualizaciones y parches de seguridad regularmente.

 • Utilizar versiones actualizadas y seguras de bibliotecas y frameworks.


Ejemplos de ataques

Explotación de configuraciones predeterminadas:

Un atacante puede acceder a la base de datos de una aplicación porque se dejaron las contraseñas predeterminadas sin cambiar. Esto permite al atacante acceder a datos sensibles almacenados en la base de datos.

Exceso de permisos:

Una aplicación móvil que solicita permisos para acceder a la ubicación, contactos y cámara, sin necesidad funcional, expone más datos de los usuarios de los que debería. Un atacante que explote una vulnerabilidad en la aplicación puede acceder a estos datos excesivos.

Opciones de depuración habilitadas en producción:

Si una aplicación tiene habilitadas opciones de depuración, un atacante puede obtener información detallada sobre el funcionamiento interno de la aplicación, incluyendo posibles puntos de entrada para exploits.

Falta de HTTPS en comunicaciones:

Una aplicación que se comunica con su servidor backend a través de HTTP permite que un atacante realice un ataque de intermediario (Man-in-the-Middle) para interceptar y manipular los datos transmitidos, incluyendo credenciales de usuario y otros datos sensibles.

Actualizaciones y parches no aplicados:

Una aplicación que utiliza una biblioteca vulnerable no actualizada puede ser explotada por un atacante para ejecutar código malicioso o comprometer datos. Las vulnerabilidades conocidas pueden ser fácilmente explotadas si no se aplican los parches de seguridad disponibles.


Vulnerabilidad M9: Insecure Data Storage

La vulnerabilidad M9, "Insecure Data Storage" (Almacenamiento Inseguro de Datos), se refiere a la falta de medidas adecuadas para proteger los datos almacenados en un dispositivo móvil. Esta vulnerabilidad puede permitir a los atacantes acceder a datos sensibles, como credenciales de usuario, información personal y datos financieros, si logran comprometer el dispositivo o acceder a sus archivos de almacenamiento.

Indicadores de riesgo

 • Datos sensibles almacenados sin cifrar en el almacenamiento local del dispositivo.

 • Utilización de APIs de almacenamiento que no proporcionan cifrado o medidas de seguridad adecuadas.

 • Datos sensibles registrados en archivos de logs accesibles.

 • Bases de datos locales que no implementan cifrado para los datos sensibles almacenados.

 • Archivos de datos sensibles que no tienen los permisos de acceso adecuadamente restringidos.


Mitigaciones recomendadas

 • Utilizar cifrado fuerte (como AES) para todos los datos sensibles almacenados localmente.

 • Implementar cifrado tanto en reposo como en tránsito.

 • Emplear las APIs de almacenamiento seguro proporcionadas por el sistema operativo (por ejemplo, Keychain en iOS y Keystore en Android).

 • Evitar el uso de almacenamiento externo no seguro para datos sensibles.

 • Almacenar la menor cantidad posible de datos sensibles localmente.

 • Considerar si es necesario almacenar ciertos datos en el dispositivo.

 • Evitar registrar datos sensibles en archivos de logs.

 • Asegurarse de que los logs estén protegidos y sean accesibles solo para usuarios autorizados.

 • Configurar permisos de archivo apropiados para restringir el acceso a datos sensibles.

 • Utilizar mecanismos de control de acceso del sistema operativo para proteger los archivos.


Ejemplos de ataques

Acceso a datos en texto plano:

Si una aplicación almacena credenciales de usuario en texto plano en el almacenamiento local, un atacante que obtenga acceso físico al dispositivo o que logre comprometerlo mediante malware puede leer estos datos sin necesidad de descifrar nada.

Explotación de APIs de almacenamiento inseguras:

Una aplicación que utiliza una API de almacenamiento sin cifrado adecuado puede permitir que un atacante acceda fácilmente a los datos almacenados a través de aplicaciones maliciosas o herramientas de análisis de datos.

Extracción de datos de logs:

Si una aplicación registra datos sensibles, como tokens de autenticación, en archivos de logs, un atacante que tenga acceso a estos archivos puede robar estos datos y comprometer cuentas de usuario.

Compromiso de bases de datos locales sin cifrar:

Si una aplicación almacena información personal en una base de datos SQLite sin cifrar, un atacante que obtenga acceso al archivo de la base de datos puede leer toda la información sin necesidad de autenticación adicional.

Acceso a archivos con permisos inapropiados:

Si los archivos que contienen datos sensibles tienen permisos de acceso demasiado amplios, cualquier aplicación o usuario del dispositivo puede acceder a ellos. Esto puede llevar a la exposición de información crítica.

Vulnerabilidad M10: Insufficient Cryptography

La vulnerabilidad M10, "Insufficient Cryptography" (Cifrado Insuficiente), se refiere al uso inadecuado o débil de técnicas de cifrado en una aplicación móvil para proteger datos sensibles. Esto puede incluir el uso de algoritmos de cifrado débiles, la implementación incorrecta de cifrado y la falta de protección adecuada de claves y datos sensibles. La insuficiencia en la implementación de la criptografía puede permitir a los atacantes acceder, modificar o comprometer datos sensibles, comprometiendo la seguridad de la aplicación y la privacidad de los usuarios.

Indicadores de riesgo

 • Implementación de algoritmos de cifrado obsoletos o débiles, como DES o RC4.

 • Utilización de claves de cifrado débiles o predecibles, como contraseñas simples o derivadas de información fácilmente accesible.

 • Datos sensibles almacenados o transmitidos sin cifrado o con cifrado insuficiente.

 • Almacenamiento inseguro de claves de cifrado, como almacenarlas en texto plano o en un almacenamiento no seguro.

 • Implementación incorrecta de protocolos de seguridad, como SSL/TLS, que pueden permitir ataques de intermediarios (Man-in-the-Middle) o exponer datos sensibles.

Mitigaciones recomendadas

 • Utilizar algoritmos de cifrado modernos y seguros, como AES, para proteger datos sensibles.

 • Evitar algoritmos obsoletos o considerados débiles.

 • Generar claves de cifrado robustas y aleatorias utilizando funciones criptográficas seguras.

 • Evitar el uso de contraseñas o patrones predecibles para la generación de claves.

 • Cifrar todos los datos sensibles tanto en reposo como en tránsito utilizando algoritmos de cifrado fuertes.

 • Utilizar bibliotecas criptográficas confiables y bien probadas para implementar el cifrado.

 • Almacenar las claves de cifrado de forma segura utilizando mecanismos como el Keychain en iOS o el Keystore en Android.

 • Evitar almacenar claves en texto plano o en lugares accesibles para aplicaciones no autorizadas.

 • Configurar y utilizar protocolos de seguridad como SSL/TLS de manera adecuada y segura.

 • Habilitar opciones de configuración seguras, como el cifrado de extremo a extremo y la validación de certificados, para proteger las comunicaciones.

Ejemplos de ataques

Ataques de fuerza bruta a claves débiles:

Un atacante puede realizar un ataque de fuerza bruta contra una clave de cifrado débil o predecible para descifrar datos sensibles almacenados o transmitidos por la aplicación.

Ataques de diccionario a contraseñas mal protegidas:

Si una aplicación almacena contraseñas de usuarios utilizando un cifrado débil o sin protección adecuada, un atacante puede utilizar un ataque de diccionario para descifrar las contraseñas y obtener acceso no autorizado a las cuentas de usuario.

Ataques Man-in-the-Middle a comunicaciones no seguras:

Si una aplicación transmite datos sensibles sin cifrar o con cifrado débil, un atacante que pueda interceptar la comunicación puede leer y modificar los datos, comprometiendo la confidencialidad e integridad de la información.

Explotación de claves de cifrado almacenadas sin protección:

Si las claves de cifrado se almacenan de forma insegura, como en texto plano en un archivo de configuración, un atacante que obtenga acceso a estas claves puede descifrar datos sensibles almacenados o transmitidos por la aplicación.

Explotación de protocolos de seguridad mal configurados:

Si una aplicación utiliza protocolos de seguridad como SSL/TLS de manera incorrecta o insegura, un atacante puede aprovecharse de debilidades en la configuración para realizar ataques de intermediario (Man-in-the-Middle) y comprometer las comunicaciones

Conclusión

Estas vulnerabilidades representan una amplia gama de riesgos de seguridad que pueden afectar a las aplicaciones móviles. Desde problemas fundamentales como el manejo inadecuado de credenciales y la falta de autenticación, hasta fallos críticos en el almacenamiento y la transmisión de datos sensibles, estas vulnerabilidades ponen en peligro la privacidad, integridad y seguridad de las aplicaciones móviles y los datos de los usuarios.

Para abordar estas vulnerabilidades de manera efectiva, es crucial implementar una combinación de medidas de seguridad técnicas y procesos de desarrollo seguros. Esto incluye la adopción de buenas prácticas de codificación, el uso adecuado de cifrado y autenticación, la implementación de controles de acceso adecuados, la realización de pruebas de seguridad exhaustivas y la capacitación del personal en cuestiones de seguridad.

Al tomar medidas proactivas para identificar, remediar y mitigar estas vulnerabilidades, las organizaciones pueden mejorar significativamente la seguridad de sus aplicaciones móviles, protegiendo así tanto a los usuarios como a los datos sensibles. La conciencia continua sobre las amenazas de seguridad móvil y el compromiso con las mejores prácticas de seguridad son esenciales para garantizar una experiencia móvil segura y confiable para todos los usuarios.