Estructura del Documento
La primera parte del MASVS contiene una descripción del modelo de seguridad y de los niveles de verificación disponibles, seguido de recomendaciones sobre cómo utilizar el estándar en la práctica. En la segunda parte se detallan los requisitos de seguridad, junto con un mapeo a los distintos niveles de verificación. Los requerimientos se han agrupado en ocho categorías (V1 a V8) basadas en el objetivo/alcance técnico. La siguiente nomenclatura se utiliza a lo largo del MASVS y la MSTG:
- Categoría de los requerimientos: MASVS-Vx, p. ej. MASVS-V2: Requerimientos de Almacenamiento de datos y Privacidad.
- Requerimiento: MASVS-Vx.y, p. ej. MASVS-V2.2: “No se debe almacenar información sensible fuera del contenedor de la aplicación o del almacenamiento de credenciales del sistema.”.
MASVS-L1: Seguridad Estándar
Una aplicación móvil que logra el nivel MASVS-L1 se adhiere a las mejores prácticas de seguridad en aplicaciones móviles. Cumple con los requerimientos básicos en términos de calidad de código, manejo de los datos sensibles e interacción con el entorno móvil. Debe existir un proceso de pruebas para verificar los controles de seguridad. Este nivel es apropiado para todas las aplicaciones móviles.
MASVS-L2: Defensa en Profundidad
MASVS-L2 introduce controles de seguridad avanzados que van más allá de los requisitos estándar. Para cumplir con el MASVS-L2, debe existir un modelo de amenazas y la seguridad debe ser una parte fundamental de la arquitectura y el diseño de la aplicación. Tomando ese modelo de amenazas como base, deben de seleccionarse e implementarse los controles del MASVS-L2 que correspondan. Este nivel es apropiado para aplicaciones que manejan datos altamente sensibles, como las aplicaciones de banca móvil.
MASVS-R: Resistencia contra la Ingeniería Inversa y la Manipulación
La aplicación cuenta con el nivel de seguridad específico para la aplicación y también es resistente a ataques específicos y claramente definidos en el lado del cliente, como alteración, modificación o ingeniería inversa para extraer código o datos sensibles. Esta aplicación aprovecha las características de seguridad del hardware o bien técnicas de protección de software suficientemente fuertes y verificables. MASVS-R es adecuado para las aplicaciones que manejan datos altamente confidenciales y puede servir como medio para proteger la propiedad intelectual o dificultar la manipulación de una aplicación.
V1: Requisitos de Arquitectura, Diseño y Modelado de Amenazas
Lista los requerimientos pertinentes a la arquitectura y al diseño de la aplicación.
Requerimientos de Verificación de Seguridad
| # | MSTG-ID | Descripción | L1 | L2 |
| 1.1 | MSTG-ARCH-1 | Todos los componentes se encuentran identificados y asegurar que son necesarios. | ✓ | ✓ |
| 1.2 | MSTG-ARCH-2 | Los controles de seguridad nunca se aplican sólo en el cliente, sino que también en los respectivos servidores. | ✓ | ✓ |
| 1.3 | MSTG-ARCH-3 | Se definió una arquitectura de alto nivel para la aplicación y los servicios y se incluyeron controles de seguridad en la misma. | ✓ | ✓ |
| 1.4 | MSTG-ARCH-4 | Se identificó claramente la información considerada sensible en el contexto de la aplicación móvil. | ✓ | ✓ |
| 1.5 | MSTG-ARCH-5 | Todos los componentes de la aplicación están definidos en términos de la lógica de negocio o las funciones de seguridad que proveen. | ✓ | |
| 1.6 | MSTG-ARCH-6 | Se realizó un modelado de amenazas para la aplicación móvil y los servicios en el que se definieron las mismas y sus contramedidas. | ✓ | |
| 1.7 | MSTG-ARCH-7 | Todos los controles de seguridad poseen una implementados centralizada. | ✓ | |
| 1.8 | MSTG-ARCH-8 | Existe una política explícita sobre el uso de claves criptográficas (si se usan) a través de todo su ciclo de vida. Idealmente siguiendo un estándar de gestión de claves como el NIST SP 800-57. | ✓ | |
| 1.9 | MSTG-ARCH-9 | Existe un mecanismo para forzar las actualizaciones de la aplicación móvil. | ✓ | |
| 1.10 | MSTG-ARCH-10 | La implementación de medidas de seguridad es una parte esencial durante todo el ciclo de vida del desarrollo de software de la aplicación. | ✓ | |
| 1.11 | MSTG-ARCH-11 | Existe una política de divualgación responsable y es llevada a cabo adecuadamente. | ✓ | |
| 1.12 | MSTG-ARCH-12 | La aplicación debería de cumplir con las leyes y regulaciones de privacidad. | ✓ | ✓ |
V2: Requerimientos de Almacenamiento de datos y Privacidad
Objetivo de Control
Implementar protecciones adicionales para dificultar la recuperación de los datos sensibles tales como credenciales del usuario y la información privada que eviten que los datos confidenciales puedan:
– Exponerse a otras aplicaciones que se ejecutan en el mismo dispositivo si se utilizan de forma inadecuada mecanismos de comunicación entre procesos del sistema operativo.
– Filtrarse involuntariamente en el almacenamiento en la nube, las copias de seguridad o la caché del teclado.
– Perderse o robarse más fácilmente que otros tipos de dispositivos, teniendo por ejemplo acceso físico.
Requerimientos de Verificación de Seguridad
| # | MSTG-ID | Descripción | L1 | L2 |
| 2.1 | MSTG-STORAGE-1 | Las funcionalidades de almacenamiento de credenciales del sistema deben de ser utilizadas para almacenar información sensible, tal como información personal, credenciales de usuario o claves criptográficas. | ✓ | ✓ |
| 2.2 | MSTG-STORAGE-2 | No se debe almacenar información sensible fuera del contenedor de la aplicación o del almacenamiento de credenciales del sistema. | ✓ | ✓ |
| 2.3 | MSTG-STORAGE-3 | No se escribe información sensible en los registros (logs) de la aplicación. | ✓ | ✓ |
| 2.4 | MSTG-STORAGE-4 | No se comparte información sensible con servicios externos salvo que sea una necesidad de la arquitectura. | ✓ | ✓ |
| 2.5 | MSTG-STORAGE-5 | Se desactiva la caché del teclado en los campos de texto que contienen información sensible. | ✓ | ✓ |
| 2.6 | MSTG-STORAGE-6 | No se expone información sensible mediante mecanismos de comunicación entre procesos (IPC). | ✓ | ✓ |
| 2.7 | MSTG-STORAGE-7 | No se expone información sensible como contraseñas y números de tarjetas de crédito a través de la interfaz o capturas de pantalla. | ✓ | ✓ |
| 2.8 | MSTG-STORAGE-8 | No se incluye información sensible en las copias de seguridad generadas por el sistema operativo. | ✓ | |
| 2.9 | MSTG-STORAGE-9 | La aplicación elimina toda información sensible de la vista cuando la aplicación pasa a un segundo plano. | ✓ | |
| 2.10 | MSTG-STORAGE-10 | La aplicación no conserva ninguna información sensible en memoria más de lo necesario y la memoria se limpia trás su uso. | ✓ | |
| 2.11 | MSTG-STORAGE-11 | La aplicación obliga a que exista una política mínima de seguridad en el dispositivo, como que el usuario deba configurar un código de acceso. | ✓ | |
| 2.12 | MSTG-STORAGE-12 | La aplicación educa al usuario acerca de los tipos de información personal que procesa y de las mejores prácticas en seguridad que el usuario debería seguir al utilizar la aplicación. | ✓ | |
| 2.13 | MSTG-STORAGE-13 | No se guarda ningún tipo de información sensible de forma local en el dispositivo móvil. En su lugar, esa información debería ser obtenida desde un sistema remoto sólo cuando es necesario y únicamente residir en memoria. | ✓ | |
| 2.14 | MSTG-STORAGE-14 | En caso de ser necesario guardar información sensible de forma local, ésta debe de ser cifrada usando una clave derivada del hardware de almacenamiento seguro, el cual debe requerir autenticación previa. | ✓ | |
| 2.15 | MSTG-STORAGE-15 | El almacenamiento local de la aplicación debe de ser borrado trás un número excesivo de intentos fallidos de autenticación. | ✓ |
V3: Requerimientos de Criptografía
Objetivo de Control
Asegurar que la aplicación utiliza criptografía siguiendo las mejores prácticas de la industria, incluyendo:
- Uso de librerías criptográficas reconocidas y probadas;
- Configuración y elección apropiada de primitivas criptográficas;
- Uso de generadores de números aleatorios suficientemente seguros.
Requerimientos de Verificación de Seguridad
| # | MSTG-ID | Descripción | L1 | L2 |
| 3.1 | MSTG-CRYPTO-1 | La aplicación no depende únicamente de criptografía simétrica cuyas claves se encuentran directamente en el código fuente de la misma. | ✓ | ✓ |
| 3.2 | MSTG-CRYPTO-2 | La aplicación utiliza implementaciones de criptografía probadas. | ✓ | ✓ |
| 3.3 | MSTG-CRYPTO-3 | La aplicación utiliza primitivas de seguridad que son apropiadas para el caso particular y su configuración y parámetros siguen las mejores prácticas de la industria. | ✓ | ✓ |
| 3.4 | MSTG-CRYPTO-4 | La aplicación no utiliza protocolos o algoritmos criptográficos ampliamente considerados obsoletos para su uso en seguridad. | ✓ | ✓ |
| 3.5 | MSTG-CRYPTO-5 | La aplicación no reutiliza una misma clave criptográfica para varios propósitos. | ✓ | ✓ |
| 3.6 | MSTG-CRYPTO-6 | Los valores aleatorios son generados utilizando un generador de números aleatorios suficientemente seguro. | ✓ | ✓ |
V4: Requerimientos de Autenticación y Manejo de Sesiones
Objetivo de Control
Requerimientos básicos sobre como manejar las cuentas y sesiones del usuario.
Requerimientos de Verificación de Seguridad
| # | MSTG-ID | Descripción | L1 | L2 |
| 4.1 | MSTG-AUTH-1 | Si la aplicación provee acceso a un servicio remoto, un mecanismo aceptable de autenticación como usuario y contraseña es realizado en el servidor remoto. | ✓ | ✓ |
| 4.2 | MSTG-AUTH-2 | Si se utiliza la gestión de sesión por estado, el servidor remoto usa tokens de acceso aleatorios para autenticar los pedidos del cliente sin requerir el envío de las credenciales del usuario en cada uno. | ✓ | ✓ |
| 4.3 | MSTG-AUTH-3 | Si se utiliza la autenticación basada en tokens sin estado, el servidor proporciona un token que se ha firmado utilizando un algoritmo seguro. | ✓ | ✓ |
| 4.4 | MSTG-AUTH-4 | Cuando el usuario cierra sesión se termina la sesión también en el servidor. | ✓ | ✓ |
| 4.5 | MSTG-AUTH-5 | Existe una política de contraseñas y es aplicada en el servidor. | ✓ | ✓ |
| 4.6 | MSTG-AUTH-6 | El servidor implementa mecanismos, cuando credenciales de autenticación son ingresadas una cantidad excesiva de veces. | ✓ | ✓ |
| 4.7 | MSTG-AUTH-7 | Las sesiones y los tokens de acceso expiran luego de un tiempo predefinido de inactividad. | ✓ | ✓ |
| 4.8 | MSTG-AUTH-8 | La autenticación biométrica, si la hay, no está asociada a eventos (p. ej. usando una API que simplemente retorna “true” o “false”), sino basada en el desbloqueo del keychain/keystore (almacenamiento seguro). | ✓ | |
| 4.9 | MSTG-AUTH-9 | El sistema remoto implementa un mecanismo de segundo factor de autenticación (2FA) y lo impone consistentemente. | ✓ | |
| 4.10 | MSTG-AUTH-10 | Para realizar transacciones críticas se requiere una autenticación adicional (step-up). | ✓ | |
| 4.11 | MSTG-AUTH-11 | La aplicación informa al usuario acerca de todas las actividades sensibles en su cuenta. El usuario es capaz de ver una lista de los dispositivos conectados, información contextual (dirección IP, localización, etc.), y es capaz de bloquear ciertos dispositivos. | ✓ | |
| 4.12 | MSTG-AUTH-12 | Los modelos de autorización deberían de ser definidos e impuestos por el sistema remoto. | ✓ | ✓ |
V5: Requerimientos de Comunicación a través de la red
Objetivo de Control
El objetivo es asegurar la confidencialidad e integridad de la información intercambiada entre la aplicación móvil y los servicios del servidor utilizando canales seguros y cifrados.
Requerimientos de Verificación de Seguridad
| # | MSTG-ID | Descripción | L1 | L2 |
| 5.1 | MSTG-NETWORK-1 | La información es enviada cifrada utilizando TLS. El canal seguro es usado consistentemente en la aplicación. | ✓ | ✓ |
| 5.2 | MSTG-NETWORK-2 | Las configuraciones del protocolo TLS siguen las mejores prácticas de la industria, o lo hacen lo mejor posible en caso de que el sistema operativo del dispositivo no soporte los estándares recomendados. | ✓ | ✓ |
| 5.3 | MSTG-NETWORK-3 | La aplicación verifica el certificado X.509 del sistema remoto al establecer el canal seguro y sólo se aceptan certificados firmados por una CA de confianza. | ✓ | ✓ |
| 5.4 | MSTG-NETWORK-4 | La aplicación utiliza su propio almacén de certificados o realiza pinning del certificado o la clave pública del servidor. Bajo ningún concepto establecerá conexiones con servidores que ofrecen otros certificados o claves, incluso si están firmados por una CA de confianza. | ✓ | |
| 5.5 | MSTG-NETWORK-5 | La aplicación no depende de un único canal de comunicaciones inseguro (email o SMS) para operaciones críticas como registro de usuarios o recuperación de cuentas. | ✓ | |
| 5.6 | MSTG-NETWORK-6 | La aplicación sólo depende de bibliotecas de conectividad y seguridad actualizadas. | ✓ |
V6: Requerimientos de Interacción con la Plataforma
Objetivo de Control
Utilizar las APIs de la plataforma y componentes estándar de una manera segura además de la comunicación entre aplicaciones (IPC).
Requerimientos de Verificación de Seguridad
| # | MSTG-ID | Descripción | L1 | L2 |
| 6.1 | MSTG-PLATFORM-1 | La aplicación requiere la cantidad de permisos mínimamente necesaria. | ✓ | ✓ |
| 6.2 | MSTG-PLATFORM-2 | Todo dato ingresado por el usuario o cualquier fuente externa debe ser validado y, si es necesario, saneado. Esto incluye información recibida por la UI o mecanismos IPC como los Intents, URLs y datos provenientes de la red. | ✓ | ✓ |
| 6.3 | MSTG-PLATFORM-3 | La aplicación no expone ninguna funcionalidad sensible a través esquemas de URL salvo que dichos mecanismos estén debidamente protegidos. | ✓ | ✓ |
| 6.4 | MSTG-PLATFORM-4 | La aplicación no expone ninguna funcionalidad sensible a través de mecanismos IPC salvo que dichos mecanismos estén debidamente protegidos. | ✓ | ✓ |
| 6.5 | MSTG-PLATFORM-5 | JavaScript se encuentra deshabilitado en los WebViews salvo que sea necesario. | ✓ | ✓ |
| 6.6 | MSTG-PLATFORM-6 | Las WebViews se configuran para permitir el mínimo de los esquemas (idealmente, sólo https). Esquemas peligrosos como file, tel y app-id están deshabilitados. | ✓ | ✓ |
| 6.7 | MSTG-PLATFORM-7 | Si objetos nativos son expuestos en WebViews, debe verificarse que cualquier componente JavaScript se carga exclusivamente desde el contenedor de la aplicación. | ✓ | ✓ |
| 6.8 | MSTG-PLATFORM-8 | La serialización de objetos, si se realiza, debe implementarse utilizando API seguras. | ✓ | ✓ |
| 6.9 | MSTG-PLATFORM-9 | La aplicación se protege contra ataques de tipo screen overlay. (sólo Android) | ✓ | |
| 6.10 | MSTG-PLATFORM-10 | La caché, el almacenamiento y los recursos cargados (JavaScript, etc.) de las WebViews deben de borrarse antes de destruir la WebView. | ✓ | |
| 6.11 | MSTG-PLATFORM-11 | Verificar que la aplicación impide el uso de teclados de terceros siempre que se introduzca información sensible. | ✓ |
V7: Requerimientos de Calidad de Código y Configuración del Compilador
Objetivo de Control
Asegurar que se siguieron las prácticas de seguridad básicas en el desarrollo de la aplicación y activaron las funcionalidades “gratuitas” ofrecidas por el compilador.
Requerimientos de Verificación de Seguridad
| # | MSTG-ID | Descripción | L1 | L2 |
| 7.1 | MSTG-CODE-1 | La aplicación es firmada y provista con un certificado válido, cuya clave privada está debidamente protegida. | ✓ | ✓ |
| 7.2 | MSTG-CODE-2 | La aplicación fue publicada en modo release y con las configuraciones apropiadas para el mismo (por ejemplo, non-debuggable). | ✓ | ✓ |
| 7.3 | MSTG-CODE-3 | Los símbolos de depuración fueron eliminados de los binarios nativos. | ✓ | ✓ |
| 7.4 | MSTG-CODE-4 | Cualquier código de depuración y/o de asistencia al desarrollador (p. ej. código de test, backdoors, configuraciones ocultas) debe ser eliminado. La aplicación no hace logs detallados de errores ni de mensajes de depuración. | ✓ | ✓ |
| 7.5 | MSTG-CODE-5 | Todos los componentes de terceros se encuentran identificados y revisados en cuanto a vulnerabilidades conocidas. | ✓ | ✓ |
| 7.6 | MSTG-CODE-6 | La aplicación captura y gestiona debidamente las posibles excepciones. | ✓ | ✓ |
| 7.7 | MSTG-CODE-7 | Los controles de seguridad deniegan el acceso por defecto. | ✓ | ✓ |
| 7.8 | MSTG-CODE-8 | En código no administrado, la memoria es solicitada, utilizada y liberada de manera correcta. | ✓ | ✓ |
| 7.9 | MSTG-CODE-9 | Las funcionalidades de seguridad gratuitas de las herramientas, tales como minificación del byte-code, protección de la pila, soporte PIE y conteo automático de referencias, se encuentran activadas. | ✓ | ✓ |
V8: Requerimientos de Resistencia ante la Ingeniería Inversa
Objetivo de Control
En esta sección se cubren protecciones recomendadas para aplicaciones que maneja o brindan acceso a información o funcionalidades sensibles. La falta de estos controles no generan vulnerabilidades – sino que, están pensados para incrementar la resistencia contra la ingeniería inversa de la aplicación, dificultándole al adversario el acceso a los datos o el entendimiento del modo de ejecución de la aplicación.
Los controles de esta sección deben aplicarse según sea necesario, basándose en una evaluación de los riesgos causados por la manipulación no autorizada de la aplicación y/o la ingeniería inversa.
Impedir el Análisis Dinámico y la Manipulación
| # | MSTG-ID | Descripción | R |
| 8.1 | MSTG-RESILIENCE-1 | La aplicación detecta y responde a la presencia de un dispositivo rooteado, ya sea alertando al usuario o finalizando la ejecución de la aplicación. | ✓ |
| 8.2 | MSTG-RESILIENCE-2 | La aplicación impide la depuración o detecta y responde a la misma. Se deben cubrir todos los protocolos de depuración. | ✓ |
| 8.3 | MSTG-RESILIENCE-3 | La aplicación detecta y responde a cualquier modificación de ejecutables y datos críticos de la propia aplicación. | ✓ |
| 8.4 | MSTG-RESILIENCE-4 | La aplicación detecta la presencia de herramientas de ingeniería inversa o frameworks comunmente utilizados. | ✓ |
| 8.5 | MSTG-RESILIENCE-5 | La aplicación detecta y responde a ser ejecutada en un emulador. | ✓ |
| 8.6 | MSTG-RESILIENCE-6 | La aplicación detecta y responde ante modificaciones de código o datos en su propio espacio de memoria. | ✓ |
| 8.7 | MSTG-RESILIENCE-7 | La aplicación implementa múltiples mecanismos de detección para los puntos del 8.1 al 8.6. Nótese que, a mayor cantidad y diversidad de mecanismos usados, mayor será la resistencia. | ✓ |
| 8.8 | MSTG-RESILIENCE-8 | Los mecanismos de detección provocan distintos tipos de respuestas, incluyendo respuestas retardadas y silenciosas. | ✓ |
| 8.9 | MSTG-RESILIENCE-9 | La ofuscación se aplica a las defensas del programa, lo que a su vez impide la desofuscación mediante análisis dinámico. | ✓ |
Asociación del Dispositivo
| # | MSTG-ID | Descripción | R |
| 8.10 | MSTG-RESILIENCE-10 | La aplicación implementa un “enlace al dispositivo” utilizando una huella del dispositivo derivado de varias propiedades únicas al mismo. | ✓ |
Impedir la Comprensión
| # | MSTG-ID | Descripción | R |
| 8.11 | MSTG-RESILIENCE-11 | Todos los archivos ejecutables y bibliotecas correspondientes a la aplicación se encuentran cifrados, o bien los segmentos importantes de código se encuentran cifrados o “empaquetados” (packed). De este modo cualquier análisis estático trivial no revelará código o datos importantes. | ✓ |
| 8.12 | MSTG-RESILIENCE-12 | Si el objetivo de la ofuscación es proteger código propietario, debe utilizarse un esquema de ofuscación apropiado para la tarea particular y robusto contra métodos de desofuscación manual y automatizada, considerando la investigación actual publicada. La eficacia del esquema de ofuscación debe verificarse mediante pruebas manuales. Nótese que, siempre que sea posible, las características de aislamiento basadas en hardware son preferibles a la ofuscación. | ✓ |
Impedir el Eavesdropping
| # | MSTG-ID | Descripción | R |
| 8.13 | MSTG-RESILIENCE-13 | A modo de defensa en profundidad, además de incluir un refuerzo (hardening) sólido de la comunicación, puede implementarse el cifrado de datos (payloads) a nivel de aplicación como medida adicional contra ataques de eavesdropping. | ✓ |
Estándar de verificación de seguridad de aplicaciones móviles OWASP:
Estándar de Verificación de Seguridad en
Aplicaciones 3.0.1
Gitbook:
https://mobile-security.gitbook.io/masvs/