OWASP - MASVS-v1 4 2-Es

(Spanish Translation)
Version v1.4.2
OWASP Mobile Application Security Verification Standard
Version v1.4.2 20 de enero de 2022

OWASP Mobile Application Security Verification Standard v1.4.2
Índice general
Prólogo 5
Sobre el Estándar 8
Copyright y Licencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Reconocimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Patrocinadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Estándar de Verificación de Seguridad de Aplicaciones Móviles 12

Modelo de Seguridad para una Aplicación Móvil . . . . . . . . . . . . . . . . . 12
Evaluación y Certificación 17
Posición de OWASP en cuanto a Certificaciones MASVS y Marcas de Confianza . 17
Guía para Certificar Aplicaciones Móviles . . . . . . . . . . . . . . . . . . . . 17
Otros Usos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
V1: Requisitos de Arquitectura, Diseño y Modelado de Amenazas 20

Objetivo de Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Requerimientos de Verificación de Seguridad . . . . . . . . . . . . . . . . . . 20
Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
V2: Requerimientos de Almacenamiento de datos y Privacidad 23

Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
V3: Requerimientos de Criptografía 27

Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
V4: Requerimientos de Autenticación y Manejo de Sesiones 29

Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
V5: Requerimientos de Comunicación a través de la red 32

Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
V6: Requerimientos de Interacción con la Plataforma 34

3

Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
V7: Requerimientos de Calidad de Código y Configuración del Compilador 37

Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
V8: Requerimientos de Resistencia ante la Ingeniería Inversa 40

Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Apéndice A: Glosario 44
Apéndice B: Referencias 48
Changelog 49
V1.3 - 13 May 2021 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
V1.2 - 7 de marzo 2020 - Release Internacional . . . . . . . . . . . . . . . . . 49
V1.2-RC - 5 de octubre de 2019 - Pre-release . . . . . . . . . . . . . . . . . . 49
V1.1.4 - 4 de julio de 2019 - Summit edition . . . . . . . . . . . . . . . . . . . 50
V1.1.3 - 9 de enero de 2019 - Pequeñas correcciones . . . . . . . . . . . . . . 50
V1.1.2 - 3 de enero de 2018 - Patrocinio e internacionalización . . . . . . . . . 51
V1.1.0 - 14 de julio de 2018 . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
V1.0 - 12 de enero de 2018 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4
Prólogo
Las revoluciones tecnológicas pueden suceder rápidamente. Hace menos de una déca-
da los smartphones eran dispositivos enormes con pequeños teclados - juguetes caros
para usuarios empresariales expertos en tecnología. Hoy los smartphones son una parte
esencial de nuestras vidas. Hemos llegado a confiar en ellos para la búsqueda de infor-
mación, la navegación y la comunicación y están presentes tanto en los negocios como
en nuestra vida social.
Cada nueva tecnología introduce nuevos riesgos de seguridad, y mantenerse al día con
estos cambios es uno de los principales retos a los que se enfrenta la industria de la
seguridad. El bando defensivo está siempre unos pasos por detrás. Por ejemplo, el modo
predeterminado para muchos fue aplicar viejas formas de hacer las cosas: los smartp-
hones son como pequeños ordenadores y las aplicaciones móviles son como el software
clásico, así que seguramente los requerimientos de seguridad son similares, ¿no?. Pero
esto no funciona así. Los sistemas operativos para smartphones son diferentes a los siste-
mas operativos de escritorio, y las aplicaciones móviles son diferentes a las aplicaciones
web. Por ejemplo, el método clásico de escaneo de virus basado en firmas no tiene senti-
do en los sistemas operativos móviles modernos: no sólo es incompatible con el modelo
de distribución de aplicaciones móviles, sino que también es técnicamente imposible de-
bido a las restricciones de aislamiento. Además, algunos tipos de vulnerabilidades, como
los desbordamientos de búfer y los problemas XSS, son menos relevantes en el contex-
to de las aplicaciones móviles que, por ejemplo, en las aplicaciones de escritorio y las
aplicaciones web (con excepciones).
Con el tiempo, la industria ha conseguido un mejor control del panorama de amenazas

móviles. Resulta que la seguridad móvil tiene que ver con la protección de los datos:
las aplicaciones almacenan nuestra información personal, imágenes, grabaciones, notas,
datos de cuentas bancarias, información empresarial, ubicación y mucho más. Actúan
como clientes que nos conectan con los servicios que utilizamos a diario, y como centros
de comunicación que procesan todos y cada uno de los mensajes que intercambiamos
con otros. Comprometer el smartphone de una persona, es obtener acceso sin filtros
a su vida. Cuando consideramos que los dispositivos móviles se pierden o roban más
fácilmente y que el malware para dispositivos móviles está aumentando, la necesidad
de protección de datos se hace aún más evidente.
Por lo tanto, un estándar de seguridad para aplicaciones móviles debe centrarse en la

forma en que las aplicaciones móviles gestionan, almacenan y protegen la información
sensible. A pesar de que los sistemas operativos móviles modernos como iOS y Android
ofrecen buenas APIs para el almacenamiento y la comunicación de datos seguros, éstas
deben ser incluidas en las aplicaciones y usadas correctamente para ser efectivas. El
almacenamiento de datos, la comunicación entre aplicaciones, el uso apropiado de las
API criptográficas y la comunicación segura a través de la red son sólo algunos de los
5
aspectos que requieren una cuidadosa consideración.
Una cuestión importante que requiere el consenso de la industria es: hasta dónde se
debe llegar exactamente para proteger la confidencialidad e integridad de los datos. Por
ejemplo, la mayoría de nosotros estaríamos de acuerdo en que una aplicación móvil de-
bería verificar el certificado del servidor en una conexión TLS. Pero, ¿qué ocurre con el
certificate pinning?, ¿el no implementarlo resultaría en una vulnerabilidad?, ¿debería ser
este un requerimiento si una aplicación maneja datos sensibles?, ¿o es contraproducen-
te?, ¿necesitamos cifrar los datos almacenados en bases de datos SQLite, a pesar de que
el sistema operativo aísla la aplicación? Lo que es apropiado para una aplicación puede
ser poco realista para otra. El MASVS es un intento de estandarizar estos requerimientos
utilizando distintos niveles de verificación que se ajustan a los diferentes escenarios de
amenaza.
Además, la aparición del malware y las herramientas de administración remota han crea-
do conciencia de que los propios sistemas operativos móviles tienen fallos, por lo que
las estrategias de aislamiento se utilizan cada vez más para proporcionar protección adi-
cional a los datos confidenciales y evitar la manipulación en el lado del cliente. Aquí es
donde las cosas se complican. Las características de seguridad por hardware y las solu-
ciones de aislamiento a nivel de sistema operativo, como Android for Work y Samsung
Knox, existen, pero no siempre están disponibles en diferentes dispositivos. A modo de
curita o tirita, es posible implementar medidas de protección basadas en software - pero
desafortunadamente, no hay estándares o procesos de prueba para verificar este tipo de
protecciones.
Como resultado, los informes de pruebas de seguridad de aplicaciones móviles están por
todas partes: por ejemplo, algunos reportan una falta de ofuscación o detección de root
en una aplicación Android como “fallo de seguridad”. Por otra parte, las medidas como el
cifrado de strings, la detección de depuradores o la ofuscación del flujo de control no se
consideran obligatorias. Sin embargo, esta forma binaria de ver las cosas no tiene sentido
porque la resistencia no es una proposición binaria: depende de las amenazas particu-
lares en el dispositivo contra las que se quiere defender. Las protecciones de software
no son inútiles, pero en última instancia pueden ser eludidas, por lo que nunca deben
utilizarse como sustituto de los controles de seguridad.
El objetivo general del MASVS es ofrecer una línea de base para la seguridad de las
aplicaciones móviles (MASVS-L1), mientras que también permite la inclusión de medidas
de defensa en profundidad (MASVS-L2) y protecciones contra las amenazas del lado del
cliente (MASVS-R). El MASVS está pensado para lograr lo siguiente:
• Proveer requerimientos para arquitectos y desarrolladores de software que buscan

desarrollar aplicaciones móviles seguras;
• Ofrecer un estándar para que la industria pueda utilizar en las revisiones de seguri-
dad de aplicaciones móviles;
6
• Clarificar el rol de los mecanismos de protección de software en la seguridad móvil

y proporcionar requerimientos para verificar su efectividad;
• Proporcionar recomendaciones específicas sobre el nivel de seguridad que se reco-
mienda para los diferentes casos de uso.
Somos conscientes de que es imposible lograr un consenso del 100% en la industria. No

obstante, esperamos que el MASVS sea útil para proporcionar orientación en las fases
de desarrollo y verificación de aplicaciones móviles. Como estándar de código abierto,
el MASVS evolucionará con el tiempo, y acogemos con gusto cualquier contribución o
sugerencia.
Por Bernhard Mueller
7
Sobre el Estándar
Bienvenido al Estándar de Verificación de Seguridad de Aplicaciones Móviles (MASVS). El

MASVS es un esfuerzo comunitario para establecer un marco de requisitos de seguridad
necesarios para diseñar, desarrollar y probar la seguridad de aplicaciones móviles iOS y
Android.
El MASVS es la culminación del esfuerzo de la comunidad y la retroalimentación con la

industria. Esperamos que este estándar evolucione con el tiempo y agradecemos todo
feedback que la comunidad pueda darnos.
La mejor manera de ponerse en contacto con nosotros es a través del canal OWASP Mobile
Project en Slack: https://owasp.slack.com/messages/project-mobile_omtg/details/
Las cuentas se pueden crear en la siguiente URL: https://owasp.slack.com/join/shared_i

nvite/zt-g398htpy-AZ40HOM1WUOZguJKbblqkw#/.
Copyright y Licencia
Copyright © 2021 The OWASP Foundation. Este documento está licenciado bajo la li-
cencia Internacional 4.0 de Creative Commons Attribution-ShareAlike 4.0. Para cualquier
reutilización o distribución, debe dejar claro los términos de la licencia de esta obra.
Reconocimientos
8
Líderes del proyecto Autor Colaboradores y revisores

principal
Sven Schleier and Bernhard Alexander Antukh, Mesheryakov Aleksey, Elderov Ali,
Carlos Holguera Mueller, Bachevsky Artem, Jeroen Beckers, Jon-Anthoney de
Sven Boer, Damien Clochard, Ben Cheney, Will Chilcutt,
Schleier, Stephen Corbiaux, Manuel Delgado, Ratchenko
Jeroen Denis, Ryan Dewhurst, @empty_jack, Ben Gardiner,
Willem- Anton Glezman, Josh Grossman, Sjoerd Langkemper,
sen and Vinícius Henrique Marangoni, Martin Marsicano,
Carlos Roberto Martelloni, @PierrickV, Julia Potapenko,
Holguera Andrew Orobator, Mehrad Rafii, Javier Ruiz, Abhinav
Sejpal, Stefaan Seys, Yogesh Sharma, Prabhant
Singh, Nikhil Soni, Anant Shrivastava, Francesco
Stillavato, Abdessamad Temmar, Pauchard Thomas,
Lukasz Wierzbicki
Idioma Traductores y revisores
Alemán Rocco Gränitz, Sven Schleier (revisor)
Chino Peter Chi, and Lex Chien, Henry Hu, Leo Wang
(Tradicional)
Chino Bob Peng, Harold Zang, Jack S

(Simplificada)
Coreano Youngjae Jeon, Jeongwon Cho, Jiyou Han, Jiyeon Sung
Español Martin Marsicano, Carlos Holguera
Francés Romuald Szkudlarek, Abderrahmane Aftahi, Christian Dong (revisor)
Hindi Mukesh Sharma, Ritesh Kumar, Atul Kunwar, Parag Dave, Devendra
Kumar Sinha, Vikrant Shah
Japonés Koki Takeyama, Riotaro Okada (revisor)
Persa Hamed Salimian, Ramin Atefinia, Dorna Azhirak, Bardiya Akbari,

Mahsa Omidvar, Alireza Mazhari, Milad Khoshdel
Portugués Mateus Polastro, Humberto Junior, Rodrigo Araujo, Maurício Ariza,

(brasilera) Fernando Galves
9
Idioma Traductores y revisores
Portugués Ana Filipa Mota, Fernando Nogueira, Filipa Gomes, Luis Fontes, Sónia
Dias
Ruso Gall Maxim, Eugen Martynov, Chelnokov Vladislav (revisor), Oprya

Egor (revisor), Tereshin Dmitry (revisor)
Este documento comenzó como un fork del Estándar de Verificación de Seguridad de

Aplicaciones de OWASP escrito por Jim Manico.
Patrocinadores
Aunque tanto el MASVS como la MSTG fueron creados y son mantenidos por la comunidad
de forma voluntaria, a veces se requiere de un poco de ayuda externa. Por lo tanto,
agradecemos a nuestros patrocinadores por proporcionar los fondos para poder contratar
editores técnicos. Ha de notarse que su patrocinio no influye en el contenido del MASVS
o la MSTG de ninguna manera. Los paquetes de patrocinio están descritos en la Wiki del
proyecto OWASP.
God Mode
OWASP MSTG
OWASP Bay Area Chapter
Honorable Benefactor
OWASP MSTG
OWASP MSTG
Good Samaritan
OWASP MSTG
10
También nos gustaría agradecer al Capítulo del Área de la Bahía de OWASP por su patro-
cinio. Por último, nos gustaría agradecer a todos los que compraron el libro en Leanpub
y nos patrocinaron de esa manera.
11
Estándar de Verificación de Seguridad de

Aplicaciones Móviles
El MASVS se puede utilizar para establecer un nivel de confianza en la seguridad de las

aplicaciones móviles. Los requerimientos fueron desarrollados con los siguientes objeti-
vos en mente:
• Uso como una métrica - Proporciona un estándar dirigido tanto a desarrolladores

como a propietarios de aplicaciones, el cual puede ser utilizado para comparar apli-
caciones en términos de seguridad;
• Uso como guía - Hace de guía durante todas las fases del desarrollo y pruebas de
seguridad de las aplicaciones móviles;
• Uso durante la compra o contratación - Proporcionar una línea base para la verifica-
ción de la seguridad de aplicaciones móviles.
Modelo de Seguridad para una Aplicación Móvil
El MASVS define dos niveles de verificación de seguridad (MASVS-L1 y MASVS-L2), así

como un conjunto de requisitos de resistencia a la ingeniería inversa (MASVS-R). El nivel
MASVS-L1 contiene requerimientos genéricos de seguridad recomendados para todas las
aplicaciones móviles, mientras que MASVS-L2 debería aplicarse a aplicaciones que ma-
nejan datos altamente sensibles. MASVS-R cubre los controles de seguridad adicionales
que se pueden aplicar si la prevención de las amenazas del lado del cliente es un objetivo
de diseño.
El cumplimiento de los requerimientos de MASVS-L1 dará como resultado una aplicación

segura que sigue las mejores prácticas de seguridad y no sufre de las vulnerabilidades
más comunes. MASVS-L2 añade controles adicionales de defensa en profundidad, tales
como SSL certificate pinning, haciendo la aplicación resistente a ataques más sofisti-
cados, siempre y cuando los controles de seguridad del sistema operativo móvil estén
intactos y que el usuario final no sea considerado como un potencial adversario. El cum-
plimiento de todos o de un subconjunto de los requerimientos de protección de software
del nivel MASVS-R ayuda a prevenir amenazas específicas del lado del cliente cuando el
usuario final es considerado malicioso y/o el sistema operativo móvil ha sido comprome-
tido.
I: Aunque recomendamos implementar los controles MASVS-L1 en toda apli-

cación, la implementación de uno o varios de los controles, o el no hacerlo,
debería ser una decisión basada en el riesgo. Dicha decisión, deberá ser comu-
nicada claramente o tomada directamente junto con los dueños del negocio.
II: Los controles de protección de software listados en MASVS-R y descritos en
12
la MSTG pueden ser eludidos y no deben nunca reemplazar los demás contro-
les de seguridad. Al contrario, su intención es añadir controles de protección
adicionales (específicos a ciertas amenazas) para las aplicaciones que ya de
por sí cumplen los requerimientos MASVS-L1 y/o MASVS-L2.
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 agrupa-
do 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.”.
Niveles de Verificación Detallados
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.
13
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 requisi-
tos 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.
Uso Recomendado
Las aplicaciones pueden ser verificadas en base a los niveles MASVS-L1 o MASVS-L2 de
acuerdo con la evaluación previa del riesgo y el nivel general de seguridad requerido.
MASVS-L1 es aplicable a todas las aplicaciones móviles, mientras que MASVS-L2 se reco-
mienda generalmente para las aplicaciones que manejan datos y/o funciones sensibles.
MASVS-R (o partes de él) puede aplicarse para verificar la resistencia frente a amenazas
específicas, como el reempaquetado o la extracción de datos sensibles, además de una
verificación de seguridad adecuada.
En resumen, los siguientes tipos de verificación están disponibles:
• MASVS-L1
• MASVS-L1+R
• MASVS-L2
• MASVS-L2+R
Las diferentes combinaciones reflejan diferentes grados de seguridad y resistencia. El ob-

jetivo es permitir la flexibilidad: por ejemplo, un juego móvil puede no requerir controles
14
de seguridad MASVS-L2, como la autenticación de doble factor por razones de usabili-

dad, pero seguramente deba intentar prevenir la manipulación del código por razones
de negocio.
Cómo Elegir el Tipo de Verificación
La implementación de los requisitos del nivel MASVS-L2 aumenta la seguridad, pero al

mismo tiempo podría aumentar el coste de desarrollo y potencialmente empeorar la ex-
periencia del usuario final (el compromiso clásico). En general, MASVS-L2 debe utilizarse
siempre que tenga sentido desde el punto de vista del riesgo frente al coste que conlleva
(es decir, cuando la potencial pérdida causada por un compromiso de confidencialidad o
integridad sea superior al coste de implementación que suponen los controles de segu-
ridad adicionales). Una evaluación de riesgo debe ser el primer paso antes de aplicar el
MASVS.
Ejemplos
MASVS-L1
• Todas las aplicaciones móviles. El nivel MASVS-L1 enumera las mejores prácticas de
seguridad que se pueden seguir con un impacto razonable en el coste de desarrollo
y la experiencia del usuario. Los requerimientos del MASVS-L1 pueden aplicarse en
cualquier aplicación no apta para los niveles superiores.
MASVS-L2
• Industria de la Salud: aplicaciones móviles que almacenan información personal

identificable que puede ser utilizada para el robo de identidad, pagos fraudulentos,
o una variedad de esquemas de fraude. Para el sector de la salud en los Estados
Unidos, las consideraciones de cumplimiento incluyen la Ley de Portabilidad y Res-
ponsabilidad del Seguro Médico (HIPAA, por sus siglas en inglés), Privacidad, Segu-
ridad, Reglas de Notificación de Violación (Breach Notification Rules) y Reglas de
Seguridad del Paciente (Patient Safety Rule).
• Sector Financiero: Aplicaciones que permiten el acceso a información altamente sen-

sible como números de tarjetas de crédito, información personal o que permiten al
usuario mover fondos. Estas aplicaciones deben tener controles de seguridad adi-
cionales para prevenir el fraude. Las aplicaciones financieras necesitan asegurar el
cumplimiento de las normas de seguridad de datos de la industria de tarjetas de
pago (PCI DSS), Gramm Leech Bliley Act y Sarbanes-Oxley Act (SOX).
MASVS L1+R
• Aplicaciones móviles donde la protección de la propiedad intelectual (IP, por sus si-
glas en inglés) es un claro objetivo empresarial. Los controles de resistencia listados
15
en MASVS-R se pueden utilizar para incrementar el esfuerzo necesario para obtener

el código fuente original y dificultar la manipulación / cracking.
• Industria de los juegos: juegos con una necesidad esencial de evitar la posibilidad de
modding y el engaño, como los juegos competitivos online. Hacer trampa es un tema
importante en los juegos online, ya que una gran cantidad de tramposos conduce a
un descontento de la base de jugadores y, en última instancia, puede causar que un
juego fracase. MASVS-R proporciona controles básicos contra la manipulación para
ayudar a incrementar el esfuerzo que los tramposos deberían realizar.
MASVS L2+R
• Industria Financiera: aplicaciones de banca móvil que permiten al usuario mover

fondos, donde las técnicas de inyección de código e instrumentación en disposi-
tivos comprometidos suponen un riesgo. En este caso, los controles MASVS-R se
pueden utilizar para dificultar la manipulación de código, dificultando el trabajo de
potenciales autores de malware.
• Todas las aplicaciones móviles que, por diseño, necesitan almacenar datos sensi-
bles en el dispositivo móvil y, al mismo tiempo, deben soportar una amplia gama
de dispositivos y versiones del sistema operativo. En este caso, los controles de
resistencia pueden utilizarse como una medida de defensa en profundidad para au-
mentar el esfuerzo de los atacantes que intentan extraer datos sensibles.
• Todas las aplicaciones que contengan “compras en la aplicación” deberían de prote-

ger su contenido de pago utilizando idealmente controles MASVS-L2 y del lado del
servidor. Sin embargo, puede haber casos en los que no sea posible implementar la
proctección del lado del servidor. En esos casos, deberían de aplicarse los controles
MASVS-R de forma adicional para incrementar el esfuerzo necesario para revertir o
manipular la aplicación.
16
Evaluación y Certificación
Posición de OWASP en cuanto a Certificaciones MASVS y Marcas de

Confianza
OWASP, como una organización sin ánimo de lucro e independiente de toda empresa, no
certifica a ningún proveedor, verificador o software.
Ninguna certificación, marca de garantía o confianza actualmente existente ha sido exa-

minada, registrada o certificada oficialmente por OWASP. Por tanto, una organización que
confía en tal opinión debe tener la precaución de la confianza depositada en cualquier
tercero o marca de confianza que alega la certificación (M)ASVS.
Esto no debe impedir que las organizaciones ofrezcan tales servicios de seguridad, siem-
pre que no reclamen la certificación oficial OWASP.
Guía para Certificar Aplicaciones Móviles
La forma recomendada de verificar la conformidad de una aplicación móvil con el MASVS

es realizar una revisión de “libro abierto”, lo que significa que los verificadores tienen
acceso a recursos claves como arquitectos y desarrolladores de la aplicación, documen-
tación del proyecto, código fuente y acceso autenticado a los terminales, incluyendo
acceso a al menos una cuenta de usuario para cada función.
Es importante tener en cuenta que el MASVS sólo cubre la seguridad de la aplicación mó-
vil (en el dispositivo del cliente) y la comunicación de red entre la aplicación y sus puntos
remotos, así como algunos requerimientos básicos y genéricos relacionados con la auten-
ticación del usuario y la gestión de sesiones. No contiene requerimientos específicos para
los servicios remotos (por ejemplo, servicios web) asociados a la aplicación, salvo para
un conjunto limitado de requerimientos genéricos relacionados con la autenticación y la
gestión de sesiones. No obstante, MASVS-V1 especifica que los servicios remotos deben
ser cubiertos por el modelo general de amenazas, y ser verificados contra los estándares
apropiados, tales como el OWASP ASVS.
Los informes creados por organismos de certificación deberían incluir los siguientes ele-
mentos considerados como práctica estándar de la industria:
• El alcance de la verificación, especialmente cuando un componente clave está fuera

de dicho alcance.
• Un resumen de los resultados de la verificación, incluyendo las pruebas superadas
y fallidas, con instrucciones claras de cómo resolver las pruebas fallidas.
• Mantener documentos de trabajo detallados, incluyendo capturas de pantalla o ví-
deos.
• Guiones para explotar de forma fiable y repetida un problema.
17
• Registros electrónicos de las pruebas, como los logs de un proxy y cualquier nota
asociada.
Nòtese que no basta con simplemente ejecutar una herramienta y presentar un informe
sobre los fallos; esto no aporta suficientes evidencias de que se han analizado y probado
a fondo todos los aspectos a nivel de una certificación. En caso de controversia, debe
haber pruebas suficientes para demostrar que todos los requerimientos verificados han
sido efectivamente probados.
Usando la Guía de Pruebas de Seguridad Móvil de OWASP (MSTG)
La OWASP MSTG es una guía para la verificación de la seguridad de las aplicaciones

móviles. Describe los procedimientos técnicos para verificar los requerimientos listados
en el MASVS. La MSTG incluye una lista de casos de prueba, cada uno de los cuales
se corresponde con un requerimiento del MASVS. Mientras que los requerimientos del
MASVS son de alto nivel y genéricos, la MSTG proporciona recomendaciones detalladas
y procedimientos de verificación para cada uno de los sistemas operativos móviles.
El Papel de las Herramientas de Pruebas de Seguridad Automatizadas
Se recomienda el uso de escáneres de código fuente y herramientas de auditoría de tipo

black-box para aumentar la eficiencia siempre que sea posible. Sin embargo, no es posi-
ble completar la verificación MASVS utilizando únicamente herramientas automatizadas:
cada aplicación móvil es diferente. Por tanto, la comprensión de la arquitectura general,
la lógica de negocio y los problemas específicos de las tecnologías y plataformas que se
utilizan es un requerimiento obligatorio para verificar la seguridad de la aplicación.
Otros Usos
Como Guía Detallada para una Arquitectura Segura
Uno de los usos más comunes del MASVS es como guía para los arquitectos de seguridad.
Los dos principales esquemas de seguridad en la arquitectura, SABSA o TOGAF, carecen
de una gran cantidad de información necesaria para completar las revisiones de seguri-
dad en la arquitectura de las aplicaciones móviles. El MASVS se puede utilizar para llenar
esos vacíos permitiendo a los arquitectos elegir los mejores controles para los problemas
comunes de seguridad en las aplicaciones móviles.
18
Como Reemplazo de las Checklists de Desarrollo Seguro de Aplicaciones

Móviles
Muchas organizaciones pueden beneficiarse de la adopción del MASVS simplemente eli-

giendo uno de los niveles, o haciendo su propio fork del MASVS y cambiando lo que se
requiera específicamente en el contexto y el nivel de riesgo de cada aplicación. Fomen-
tamos este tipo de forks siempre y cuando se mantenga la trazabilidad, de modo que si
una aplicación cumple con un requerimiento del MASVS original, lo mismo ocurre en los
forks del estándar cuando éste evoluciona.
Como Base para las Metodologías de Pruebas de Seguridad
Una buena metodología de pruebas de seguridad para aplicaciones móviles debe cubrir
todos los requerimientos listados en el MASVS. La OWASP MSTG describe los casos de
prueba de tipo black-box y white-box para cada requerimiento de verificación.
Como Guía para la Automatización de Pruebas Unitarias y de Integración
El MASVS está diseñado para ser altamente verificable, con la única excepción de los
requerimientos de arquitectura. Las pruebas unitarias, de integración y de aceptación
automatizadas, basadas en los requerimientos del MASVS, pueden integrarse en el ciclo
de vida de desarrollo de software (SDLC, por sus siglas en inglés). Esto no sólo aumenta
la conciencia de seguridad de los desarrolladores, sino que también mejora la calidad
general de las aplicaciones desarrolladas, y reduce la cantidad de hallazgos durante las
pruebas de seguridad en la fase previa al release.
Para el Entrenamiento en Desarrollo Seguro
El MASVS también se puede utilizar para definir características de aplicaciones móviles

seguras. Muchos cursos de “desarrollo segura” son simplemente cursos de hacking ético
con algunos consejos de programación segura. Esto no ayuda a los desarrolladores. En su
lugar, los cursos de desarrollo seguro de aplicaciones móviles pueden utilizar el MASVS,
con un fuerte enfoque en los controles proactivos documentados en el MASVS, en lugar
de basarse simplemente en, por ejemplo, el “Top 10 de problemas de seguridad en el
desarrollo software”.
19
V1: Requisitos de Arquitectura, Diseño y

Modelado de Amenazas
Objetivo de Control
En un mundo perfecto, la seguridad sería considerada en todas las fases del desarrollo.
Sin embargo, en la realidad, la seguridad es a menudo sólo considerada en una etapa
tardía del desarrollo del software. Además de los controles técnicos, el MASVS requiere
que existan procesos que garanticen que la seguridad se ha abordado explícitamente al
planificar la arquitectura de la aplicación móvil, y que se conocen los roles funcionales
y de seguridad de todos los componentes. Dado que la mayoría de las aplicaciones mó-
viles actúan como clientes de los servicios remotos, debe garantizarse que también se
apliquen las medidas de seguridad adecuadas a dichos servicios, no basta con probar la
aplicación móvil de forma aislada.
La categoría V1 lista los requerimientos pertinentes a la arquitectura y al diseño de la

aplicación. Debido a esto es la única categoría que no se corresponde con casos de test
de la Guía de Pruebas Móviles de OWASP. Para cubrir temas tales como el modelado
de amenazas, SDLC seguro, gestión de claves, los usuarios del MASVS deben consultar
los respectivos proyectos de OWASP y/u otros estándares como los que se encuentran
enlazados a debajo.
Requerimientos de Verificación de Seguridad
A continuación, se enumeran los requerimientos para MASVS-L1 y MASVS-L2.
# MSTG-ID Descripción L1 L2
1.1 MSTG-ARCH-1 Todos los componentes se encuentran x x

identificados y asegurar que son necesarios.
1.2 MSTG-ARCH-2 Los controles de seguridad nunca se aplican x x

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 x x

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 x x

considerada sensible en el contexto de la
aplicación móvil.
20
1.5 MSTG-ARCH-5 Todos los componentes de la aplicación están x

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 x

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 x

implementados centralizada.
1.8 MSTG-ARCH-8 Existe una política explícita sobre el uso de x

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 x

actualizaciones de la aplicación móvil.
1.10 MSTG-ARCH-10 La implementación de medidas de seguridad es x

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 x

y es llevada a cabo adecuadamente.
1.12 MSTG-ARCH-12 La aplicación debería de cumplir con las leyes y x x

regulaciones de privacidad.
Referencias
Para más información, ver también:
• OWASP Top 10 Móvil: M10 (Funcionalidades Extrañas) - <hhttps://owasp.org/www-

project-mobile-top-10/2016-risks/m10-extraneous-functionality>
• Modelado de Amenazas (OWASP) - https://owasp.org/www-community/Applicatio
n_Threat_Modeling
• “Cheat Sheet” del Ciclo de Vida del Desarrollo Software Seguro (OWASP) - https:
//github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets_excluded/Secure
21
_SDLC_Cheat_Sheet.md
• Microsoft SDL - https://www.microsoft.com/en-us/sdl/
• NIST SP 800-57 (Recomendación de Gestión de Claves) - https://csrc.nist.gov/publ
ications/detail/sp/800-57-part-1/rev-5/final
• security.txt - https://securitytxt.org/
22
V2: Requerimientos de Almacenamiento de datos

y Privacidad
Objetivo de Control
La protección de datos sensibles, como las credenciales del usuario y la información pri-
vada, es un aspecto clave de la seguridad móvil. En primer lugar, los datos confidenciales
pueden exponerse involuntariamente a otras aplicaciones que se ejecutan en el mismo
dispositivo si se utilizan de forma inadecuada mecanismos de comunicación entre pro-
cesos del sistema operativo. Los datos también pueden filtrarse involuntariamente en el
almacenamiento en la nube, las copias de seguridad o la caché del teclado. Además, los
dispositivos móviles pueden perderse o robarse más fácilmente que otros tipos de dispo-
sitivos, por lo que un adversario que obtiene acceso físico al mismo es un escenario más
probable. En ese caso, se pueden implementar protecciones adicionales para dificultar
la recuperación de los datos sensibles.
El MASVS se centra en las aplicaciones y por esto no cubre políticas para el dispositivo
como Mobile Device Managment (MDM) (https://gsuite.google.com/products/admin/m
obile/) o Enter (EDM). Igualmente se recomienda utilizar estas soluciones en contextos
empresariales.
Definición de Datos Sensibles
Los datos sensibles en el contexto del MASVS se refieren tanto a las credenciales de
usuario como a cualquier otro dato que se considere sensible en el contexto particular,
por ejemplo:
• Información de identificación personal que puede ser usada para el robo de identi-
dad: números de seguro social, números de tarjetas de crédito, números de cuentas
bancarias, información médica;
• Datos altamente confidenciales que, en caso de que se comprometieran, ocasiona-
rían daños a la reputación y/o costes financieros: información contractual, informa-
ción cubierta por acuerdos de confidencialidad, información de gestión;
• Cualquier dato que debe ser protegido por ley o por razones de conformidad.
La gran mayoría de las cuestiones relativas a la divulgación de datos pueden prevenirse

siguiendo reglas sencillas. La mayoría de los controles enumerados en este capítulo son
obligatorios para todos los niveles de verificación.
23
2.1 MSTG-STORAGE-1 Las funcionalidades de almacenamiento de x x

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 x x

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 x x

registros (logs) de la aplicación.
2.4 MSTG-STORAGE-4 No se comparte información sensible con x x

servicios externos salvo que sea una necesidad
de la arquitectura.
2.5 MSTG-STORAGE-5 Se desactiva la caché del teclado en los campos x x

de texto que contienen información sensible.
2.6 MSTG-STORAGE-6 No se expone información sensible mediante x x

mecanismos de comunicación entre procesos
(IPC).
2.7 MSTG-STORAGE-7 No se expone información sensible como x x

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 x

de seguridad generadas por el sistema
operativo.
2.9 MSTG-STORAGE-9 La aplicación elimina toda información sensible x

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 x

sensible en memoria más de lo necesario y la
memoria se limpia trás su uso.
24
2.11 MSTG-STORAGE-11 La aplicación obliga a que exista una política x

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 x x

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 x

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 x

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 x

de ser borrado trás un número excesivo de
intentos fallidos de autenticación.
Referencias
La Guía de Pruebas de Seguridad Móvil de OWASP proporciona instrucciones detalladas

para verificar los requisitos listados en esta sección.
• Android - https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05d-
Testing-Data-Storage.md
• iOS - https://github.com/OWASP/owasp- mstg/blob/master/Document/0x06d-
Testing-Data-Storage.md
• OWASP Mobile Top 10: M1 (Improper Platform Usage) - https://owasp.org/www-

project-mobile-top-10/2016-risks/m1-improper-platform-usage
25
• OWASP Mobile Top 10: M2 (Insecure Data Storage) - https://owasp.org/www-project-

mobile-top-10/2016-risks/m2-insecure-data-storage
• CWE 117 (Improper Output Neutralization for Logs) - https://cwe.mitre.org/data/def
initions/117.html
• CWE 200 (Information Exposure) - https://cwe.mitre.org/data/definitions/200.html
• CWE 276 (Incorrect Default Permissions) - https://cwe.mitre.org/data/definitions/2
76.html
• CWE 311 (Missing Encryption of Sensitive Data) - https://cwe.mitre.org/data/definit
ions/311.html
• CWE 312 (Cleartext Storage of Sensitive Information) - https://cwe.mitre.org/data/d
efinitions/312.html
• CWE 316 (Cleartext Storage of Sensitive Information in Memory) - https://cwe.mitr
e.org/data/definitions/316.html
• CWE 359 (Exposure of Private Information (‘Privacy Violation’)) - https://cwe.mitre.
org/data/definitions/359.html
• CWE 522 (Insufficiently Protected Credentials) - https://cwe.mitre.org/data/definitio
ns/522.html
• CWE 524 (Information Exposure Through Caching) - https://cwe.mitre.org/data/def
initions/524.html
• CWE 530 (Exposure of Backup File to an Unauthorized Control Sphere) - https://cwe.
mitre.org/data/definitions/530.html
• CWE 532 (Information Exposure Through Log Files) - https://cwe.mitre.org/data/def
initions/532.html
• CWE 534 (Information Exposure Through Debug Log Files) - https://cwe.mitre.org/
data/definitions/534.html
• CWE 634 (Weaknesses that Affect System Processes) - https://cwe.mitre.org/data/d
efinitions/634.html
• CWE 798 (Use of Hard-coded Credentials) - https://cwe.mitre.org/data/definitions/7
98.html
• CWE 921 (Storage of Sensitive Data in a Mechanism without Access Control) - https:
//cwe.mitre.org/data/definitions/921.html
• CWE 922 (Insecure Storage of Sensitive Information) - https://cwe.mitre.org/data/d
efinitions/922.html
26
V3: Requerimientos de Criptografía
Objetivo de Control
La criptografía es un componente esencial a la hora de proteger los datos almacenados en

un dispositivo móvil. También es una categoría en la que las cosas pueden ir terriblemente
mal, especialmente cuando no se siguen las convenciones estándar. El propósito de estos
controles es asegurarse de 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.
3.1 MSTG-CRYPTO-1 La aplicación no depende únicamente de x x

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 x x

criptografía probadas.
3.3 MSTG-CRYPTO-3 La aplicación utiliza primitivas de seguridad que x x

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 x x

criptográficos ampliamente considerados
obsoletos para su uso en seguridad.
3.5 MSTG-CRYPTO-5 La aplicación no reutiliza una misma clave x x

criptográfica para varios propósitos.
3.6 MSTG-CRYPTO-6 Los valores aleatorios son generados utilizando x x

un generador de números aleatorios
suficientemente seguro.
27
Referencias

• Android - https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05e-
Testing-Cryptography.md
• iOS - https://github.com/OWASP/owasp- mstg/blob/master/Document/0x06e-
Testing-Cryptography.md
• OWASP Mobile Top 10: M5 (Insufficient Cryptography) - https://owasp.org/www-

project-mobile-top-10/2016-risks/m5-insufficient-cryptography
• CWE 310 (Cryptographic Issues) - https://cwe.mitre.org/data/definitions/310.html
• CWE 321 (Use of Hard-coded Cryptographic Key) - https://cwe.mitre.org/data/defin
itions/321.html
• CWE 326 (Inadequate Encryption Strength) - https://cwe.mitre.org/data/definitions
/326.html
• CWE 327 (Use of a Broken or Risky Cryptographic Algorithm) - https://cwe.mitre.or
g/data/definitions/327.html
• CWE 329 (Not Using a Random IV with CBC Mode) - https://cwe.mitre.org/data/def
initions/329.html
• CWE 330 (Use of Insufficiently Random Values) - https://cwe.mitre.org/data/definit
ions/330.html
• CWE 337 (Predictable Seed in PRNG) - https://cwe.mitre.org/data/definitions/337.h
tml
• CWE 338 (Use of Cryptographically Weak Pseudo Random Number Generator
(PRNG)) - https://cwe.mitre.org/data/definitions/338.html
28
V4: Requerimientos de Autenticación y Manejo

de Sesiones
Objetivo de Control
En la mayoría de los casos, una parte esencial de la arquitectura global de aplicaciones

móviles es que los usuarios deben inician sesión en un servicio remoto. Aunque la mayor
parte de la lógica ocurre en el servidor, MASVS define algunos requerimientos básicos
sobre como manejar las cuentas y sesiones del usuario.
4.1 MSTG-AUTH-1 Si la aplicación provee acceso a un servicio x x

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 x x

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 x x

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 x x

sesión también en el servidor.
4.5 MSTG-AUTH-5 Existe una política de contraseñas y es aplicada x x

en el servidor.
4.6 MSTG-AUTH-6 El servidor implementa mecanismos, cuando x x

credenciales de autenticación son ingresadas
una cantidad excesiva de veces.
4.7 MSTG-AUTH-7 Las sesiones y los tokens de acceso expiran x x

luego de un tiempo predefinido de inactividad.
29
4.8 MSTG-AUTH-8 La autenticación biométrica, si la hay, no está x

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 x

de segundo factor de autenticación (2FA) y lo
impone consistentemente.
4.10 MSTG-AUTH-10 Para realizar transacciones críticas se requiere x

una autenticación adicional (step-up).
4.11 MSTG-AUTH-11 La aplicación informa al usuario acerca de todas x

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 x x

definidos e impuestos por el sistema remoto.
Referencias

• General - https://github.com/OWASP/owasp-mstg/blob/master/Document/0x04e-
Testing-Authentication-and-Session-Management.md
• Android - https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05f-
Testing-Local-Authentication.md
• iOS - https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06f-Testing-
Local-Authentication.md
• OWASP Mobile Top 10: M4 (Insecure Authentication) - https://owasp.org/www-proj

ect-mobile-top-10/2016-risks/m4-insecure-authentication
• OWASP Mobile Top 10: M6 (Insecure Authorization) - https://owasp.org/www-project-
mobile-top-10/2016-risks/m6-insecure-authorization
30
• CWE 287 (Improper Authentication) - https://cwe.mitre.org/data/definitions/287.h

tml
• CWE 307 (Improper Restriction of Excessive Authentication Attempts) - https://cwe.
• CWE 308 (Use of Single-factor Authentication) - https://cwe.mitre.org/data/definitio
ns/308.html
• CWE 521 (Weak Password Requirements) - https://cwe.mitre.org/data/definitions/5
21.html
• CWE 604 (Use of Client-Side Authentication) - https://cwe.mitre.org/data/definitions
/604.html
• CWE 613 (Insufficient Session Expiration) - https://cwe.mitre.org/data/definitions/6
13.html
31
V5: Requerimientos de Comunicación a través de

la red
Objetivo de Control
Los controles enumerados en esta categoría tienen por objetivo asegurar la confidenciali-
dad e integridad de la información intercambiada entre la aplicación móvil y los servicios
del servidor. Como mínimo se deben utilizar canales seguros y cifrados utilizando el pro-
tocolo TLS con las configuraciones apropiadas. En el nivel 2 se establecen medidas en
profundidad como fijación de certificados SSL.
5.1 MSTG-NETWORK-1 La información es enviada cifrada utilizando TLS. x x

El canal seguro es usado consistentemente en
la aplicación.
5.2 MSTG-NETWORK-2 Las configuraciones del protocolo TLS siguen las x x

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 x x

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 x

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 x

comunicaciones inseguro (email o SMS) para
operaciones críticas como registro de usuarios o
recuperación de cuentas.
32
5.6 MSTG-NETWORK-6 La aplicación sólo depende de bibliotecas de x

conectividad y seguridad actualizadas.
Referencias

• Android - https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05g-
Testing-Network-Communication.md
• iOS - https://github.com/OWASP/owasp- mstg/blob/master/Document/0x06g-
Testing-Network-Communication.md
• OWASP Mobile Top 10: M3 (Insecure Communication) - https://owasp.org/www-

project-mobile-top-10/2016-risks/m3-insecure-communication
• CWE 295 (Improper Certificate Validation) - https://cwe.mitre.org/data/definitions/2
95.html
• CWE 296 (Improper Following of a Certificate’s Chain of Trust) - https://cwe.mitre.or
• CWE 297 (Improper Validation of Certificate with Host Mismatch) - https://cwe.mitr
e.org/data/definitions/297.html
• CWE 298 (Improper Validation of Certificate Expiration) - https://cwe.mitre.org/data
/definitions/298.html
• CWE 308 (Use of Single-factor Authentication) - https://cwe.mitre.org/data/definitio
ns/308.html
• CWE 319 (Cleartext Transmission of Sensitive Information) - https://cwe.mitre.org/
data/definitions/319.html
• CWE 326 (Inadequate Encryption Strength) - https://cwe.mitre.org/data/definitions
/326.html
• CWE 327 (Use of a Broken or Risky Cryptographic Algorithm) - https://cwe.mitre.or
• CWE 780 (Use of RSA Algorithm without OAEP) - https://cwe.mitre.org/data/definit
ions/780.html
• CWE 940 (Improper Verification of Source of a Communication Channel) - https:
• CWE 941 (Incorrectly Specified Destination in a Communication Channel) - https:
33
V6: Requerimientos de Interacción con la

Plataforma
Objetivo de Control
Estos controles revisan que se utilicen las APIs de la plataforma y componentes estándar
de una manera segura. Además, se cubre la comunicación entre aplicaciones (IPC).
6.1 MSTG-PLATFORM-1 La aplicación requiere la cantidad de permisos x x

mínimamente necesaria.
6.2 MSTG-PLATFORM-2 Todo dato ingresado por el usuario o cualquier x x

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 x x

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 x x

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 x x

WebViews salvo que sea necesario.
6.6 MSTG-PLATFORM-6 Las WebViews se configuran para permitir el x x

mínimo de los esquemas (idealmente, sólo
https). Esquemas peligrosos como file, tel y
app-id están deshabilitados.
34
6.7 MSTG-PLATFORM-7 Si objetos nativos son expuestos en WebViews, x x

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 x x

implementarse utilizando API seguras.
6.9 MSTG-PLATFORM-9 La aplicación se protege contra ataques de tipo x

screen overlay. (sólo Android)
6.10 MSTG-PLATFORM-10 La caché, el almacenamiento y los recursos x

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 x

teclados de terceros siempre que se introduzca
información sensible. (sólo iOS)
Referencias

• Android - https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05h-
Testing-Platform-Interaction.md
• iOS - https://github.com/OWASP/owasp- mstg/blob/master/Document/0x06h-
Testing-Platform-Interaction.md
• OWASP Mobile Top 10: M1 (Improper Platform Usage) - https://owasp.org/www-

project-mobile-top-10/2016-risks/m1-improper-platform-usage
• OWASP Mobile Top 10: M7 (Poor Code Quality) - https://owasp.org/www-project-
mobile-top-10/2016-risks/m7-client-code-quality
• CWE 20 (Improper Input Validation) - https://cwe.mitre.org/data/definitions/20.html
• CWE 79 (Improper Neutralization of Input During Web Page Generation) - https:
• CWE 200 (Information Leak / Disclosure) - https://cwe.mitre.org/data/definitions/2
00.html
35
• CWE 250 (Execution with Unnecessary Privileges) - https://cwe.mitre.org/data/defin

itions/250.html
• CWE 672 (Operation on a Resource after Expiration or Release) - https://cwe.mitre.
• CWE 749 (Exposed Dangerous Method or Function) - https://cwe.mitre.org/data/def
initions/749.html
• CWE 772 (Missing Release of Resource after Effective Lifetime) - https://cwe.mitre.
• CWE 920 (Improper Restriction of Power Consumption) - https://cwe.mitre.org/data
/definitions/920.html
• CWE 925 (Improper Verification of Intent by Broadcast Receiver) - https://cwe.mitre.
• CWE 926 (Improper Export of Android Application Components) - https://cwe.mitre.
• CWE 927 (Use of Implicit Intent for Sensitive Communication) - https://cwe.mitre.or
• CWE 939 (Improper Authorization in Handler for Custom URL Scheme) - https://cwe.
36
V7: Requerimientos de Calidad de Código y

Configuración del Compilador
Objetivo de Control
Estos controles buscan asegurar que se siguieron las prácticas de seguridad básicas en
el desarrollo de la aplicación. Y que se activaron las funcionalidades “gratuitas” ofrecidas
por el compilador.
7.1 MSTG-CODE-1 La aplicación es firmada y provista con un x x

certificado válido, cuya clave privada está
debidamente protegida.
7.2 MSTG-CODE-2 La aplicación fue publicada en modo release y x x

con las configuraciones apropiadas para el
mismo (por ejemplo, non-debuggable).
7.3 MSTG-CODE-3 Los símbolos de depuración fueron eliminados x x

de los binarios nativos.
7.4 MSTG-CODE-4 Cualquier código de depuración y/o de x x

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 x x

encuentran identificados y revisados en cuanto
a vulnerabilidades conocidas.
7.6 MSTG-CODE-6 La aplicación captura y gestiona debidamente x x

las posibles excepciones.
7.7 MSTG-CODE-7 Los controles de seguridad deniegan el acceso x x

por defecto.
37
7.8 MSTG-CODE-8 En código no administrado, la memoria es x x

solicitada, utilizada y liberada de manera
correcta.
7.9 MSTG-CODE-9 Las funcionalidades de seguridad gratuitas de x x

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.
Referencias

• Android - https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05i-
Testing-Code-Quality-and-Build-Settings.md
• iOS - https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06i-Testing-
Code-Quality-and-Build-Settings.md
• OWASP Mobile Top 10: M7 (Poor Code Quality) - https://owasp.org/www-project-

mobile-top-10/2016-risks/m7-client-code-quality
• CWE 20 (Improper Input Validation) - https://cwe.mitre.org/data/definitions/20.html
• CWE 89 (Improper Neutralization of Special Elements used in an SQL Command) -
https://cwe.mitre.org/data/definitions/89.html
• CWE 95 (Improper Neutralization of Directives in Dynamically Evaluated Code (‘Eval
Injection’)) - https://cwe.mitre.org/data/definitions/95.html
• CWE 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)
- https://cwe.mitre.org/data/definitions/119.html
• CWE 215 (Information Exposure through Debug Information) - https://cwe.mitre.or
• CWE 388 (7PK - Errors) - https://cwe.mitre.org/data/definitions/388.html
• CWE 489 (Leftover Debug Code) - https://cwe.mitre.org/data/definitions/489.html
• CWE 502 (Deserialization of Untrusted Data) - https://cwe.mitre.org/data/definitio
ns/502.html
• CWE 511 (Logic/Time Bomb) - https://cwe.mitre.org/data/definitions/511.html
• CWE 656 (Reliance on Security through Obscurity) - https://cwe.mitre.org/data/def
initions/656.html
38
• CWE 676 (Use of Potentially Dangerous Function) - https://cwe.mitre.org/data/defin

itions/676.html
• CWE 937 (OWASP Top Ten 2013 Category A9 - Using Components with Known Vulne-
rabilities) - https://cwe.mitre.org/data/definitions/937.html
39
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 del código. Sugerimos consultar el documento de OWASP “In-
geniería Inversa - Amenazas de la Ingeniería Inversa de OWASP” (vea las referencias a
continuación) para obtener una lista de los riesgos del negocio, así como las amenazas
técnicas asociadas.
Para que cualquiera de los controles de la lista siguiente sea eficaz, la aplicación debe
cumplir al menos todos los requerimientos del nivel MASVS-L1 (es decir, deben existir só-
lidos controles de seguridad), así como todos los requerimientos de números más bajos
en V8. Por ejemplo, los controles de ofuscación listados en la sección “impedir la com-
prensión” deben combinarse con el “impedir el análisis dinámico y la manipulación” y la
“atadura al dispositivo”.
Tenga en cuenta que los controles de software nunca deben utilizarse como
reemplazo de los controles de seguridad. Los controles listados en MASVR-
R buscan añadir controles de protección adicionales y específicos contra las
amenazas a las aplicaciones que también cumplen con los requerimientos de
seguridad del MASVS.
Se aplican las siguientes consideraciones:
1. Debe definirse un modelo de amenaza que defienda claramente las amenazas del
lado del cliente. Además, debe especificarse el grado de protección que debe pro-
porcionar el sistema. Por ejemplo, un objetivo podría ser obligar a los autores de
malware dirigido que quieren usar la aplicación a que tengan que invertir importan-
tes esfuerzos para realizar la ingeniería inversa.
2. El modelo de amenaza debe ser sensato. Por ejemplo, ocultar una clave criptográ-
fica en una implementación de caja blanca es un problema si el atacante puede
simplemente utilizar la aplicación como un todo.
3. La eficiencia de la protección siempre debe ser verificada por un experto con expe-
riencia en el testeo de tipos particulares de anti-manipulación y ofuscación utiliza-
40
dos (ver también los capítulos “ingeniería inversa” y “evaluación de protecciones

del software” en la Guía de Pruebas de Seguridad Móvil).
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 x

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 x

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 x

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 x

herramientas de ingeniería inversa o frameworks
comunmente utilizados.
8.5 MSTG-RESILIENCE-5 La aplicación detecta y responde a ser ejecutada x

en un emulador.
8.6 MSTG-RESILIENCE-6 La aplicación detecta y responde ante x

modificaciones de código o datos en su propio
espacio de memoria.
8.7 MSTG-RESILIENCE-7 La aplicación implementa múltiples mecanismos x

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 x

tipos de respuestas, incluyendo respuestas
retardadas y silenciosas.
8.9 MSTG-RESILIENCE-9 La ofuscación se aplica a las defensas del x

programa, lo que a su vez impide la
desofuscación mediante análisis dinámico.
41
Asociación del Dispositivo
8.10 MSTG-RESILIENCE-10 La aplicación implementa un “enlace al x

dispositivo” utilizando una huella del dispositivo
derivado de varias propiedades únicas al mismo.
Impedir la Comprensión
8.11 MSTG-RESILIENCE-11 Todos los archivos ejecutables y bibliotecas x

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 x

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
42
8.13 MSTG-RESILIENCE-13 A modo de defensa en profundidad, además de x

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.
Referencias

• Android - https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05j-
Testing-Resiliency-Against-Reverse-Engineering.md
• iOS - https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06j-Testing-
Resiliency-Against-Reverse-Engineering.md
• OWASP Top 10 Móvil: M8 (Modificación de Código) - https://owasp.org/www-project-

mobile-top-10/2016-risks/m8-code-tampering
• OWASP Top 10 Móvil: M9 (Ingeniería Inversa) - https://owasp.org/www- project-
mobile-top-10/2016-risks/m9-reverse-engineering
• Amenazas de Ingeniería Inversa (OWASP) - https://wiki.owasp.org/index.php/Techn
ical_Risks_of_Reverse_Engineering_and_Unauthorized_Code_Modification
• Ingeniería Inversa y Prevención de Modificación de Código (OWASP) - https://wiki.o
wasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevent
ion_Project
43
Apéndice A: Glosario
• Aleatorización del Espacio de Direcciones (ASLR) – Una técnica para hacer

más difícil la explotación de errores de corrupción de memoria.
• Seguridad de Aplicación – La seguridad a nivel de aplicación se centra en el aná-
lisis de los componentes que componen la capa de aplicación del modelo de refe-
rencia de interconexión de sistemas abiertos (modelo OSI), en lugar de centrarse,
por ejemplo, en el sistema operativo subyacente o las redes conectadas.
• Verificación de la Seguridad de una Aplicación – La evaluación técnica de una
aplicación utilizando el OWASP MASVS.
• Informe de la Verificación de la Seguridad de una Aplicación – Un informe
que documenta los resultados generales y el análisis detallado producido por el
verificador para una aplicación particular.
• Autenticación – La verificación de la identidad alegada por el usuario de una apli-
cación.
• Verificación Automatizada – El uso de herramientas automatizadas (herramien-
tas de análisis dinámico, estático o ambas) que utilizan firmas de vulnerabilidades
para encontrar problemas.
• Verificación de tipo Back-box – Es un método de verificación de software que exa-
mina la funcionalidad de una aplicación sin tener en cuenta sus estructuras internas
ni su funcionamiento.
• Componente – Una unidad de código autónoma, con un disco asociado e interfaces
de red que se comunican con otros componentes.
• Cross-Site Scripting (XSS) – Una vulnerabilidad de seguridad que normalmente
se encuentra en las aplicaciones web que permiten la inyección de scripts en el
contenido del lado del cliente.
• Módulo Criptográfico – Hardware, software y/o firmware que implementa algorit-
mos criptográficos y/o genera claves criptográficas.
• CWE – CWE es una lista de debilidades comunes de seguridad de software desarro-
llada por la comunidad. Sirve como un lenguaje común, un instrumento de medición
para las herramientas de seguridad de software, y como una línea base para la iden-
tificación de debilidades, mitigación y esfuerzos de prevención.
• Pruebas Dinámicas de Seguridad de Aplicaciones (DAST) – Las tecnologías
de Pruebas Dinámicas de Seguridad de Aplicaciones (DAST, por sus siglas en inglés)
están diseñadas para detectar indicios de vulnerabilidades de seguridad en una
aplicación mientras se está ejecutando.
• Verificaciones de Diseño – La evaluación técnica de la seguridad de la arquitec-
tura de una aplicación.
• Verificación Dinámica – El uso de herramientas automatizadas que utilizan firmas
de vulnerabilidades para encontrar problemas durante la ejecución de una aplica-
ción.
44
• Identificador Único Global (GUID) – Un número de referencia único utilizado co-

mo identificador en el software.
• Hyper Text Transfer Protocol (HTTP) – Un protocolo de aplicación para sistemas
de información distribuidos y colaborativos. Es la base de la comunicación de datos
para la World Wide Web.
• Claves Grabadas (Hardcoded keys) – Claves criptográficas que se encuentran
almacenadas directamente en el dispositivo.
• Comunicación Entre Procesos – La comunicación entre procesos (IPC, por sus
siglas en inglés) es un método mediante el cual un proceso se comunica con otro a
través del kernel del dispositivo para coordinar sus actividades.
• Validación de la Entrada – La canonización y validación de las entradas de usuario
no confiables.
• JAVA Bytecode – Java bytecode es el conjunto de instrucciones de la máquina vir-
tual Java (JVM). Cada bytecode está compuesto por uno, o en algunos casos dos
bytes que representan la instrucción (opcode), junto con cero o más bytes para pa-
sar parámetros.
• Código Malicioso – Código introducido en una aplicación durante su desarrollo
que es desconocido para el propietario de la aplicación y que elude la política de
seguridad alegada por la misma. ¡No es lo mismo que malware, virus o gusano!
• Malware – Código ejecutable que se introduce en una aplicación durante el tiempo
de ejecución sin el conocimiento del usuario o administrador de la misma.
• Open Web Application Security Project (OWASP) – OWASP es una comuni-
dad abierta a nivel mundial y sin ánimo de lucro enfocada en mejorar la seguri-
dad del software de aplicaciones. Nuestra misión es hacer que la seguridad de las
aplicaciones sea “visible” para que las personas y las organizaciones puedan to-
mar decisiones informadas sobre los riesgos de seguridad de las aplicaciones. Ver:
https://www.owasp.org/
• Información de Identificación Personal (PII) - La información de identificación
personal (PII, por sus siglas en inglés) es la información que se puede utilizar por sí
sola o junto con otra información para identificar, contactar o localizar a una sola
persona, o para identificar a un individuo en su contexto.
• Ejecutable de Posición Independiente (PIE) – Es un ejecutable que, al ser car-
gado en memoria, se ejecuta correctamente independientemente de su dirección
absoluta.
• Infraestructura de Clave Pública (PKI) – Una PKI es un acuerdo que vincula
claves públicas con las identidades respectivas de las entidades. La vinculación se
establece mediante un proceso de registro y expedición de certificados realizado
por una autoridad de certificación (CA).
• Pruebas Estáticas de Seguridad de Aplicaciones (SAST) – Las pruebas estáti-
cas de seguridad de aplicaciones (SAST) son un conjunto de tecnologías diseñadas
para analizar el código fuente de la aplicación, el bytecode, los binarios del código
45
y las condiciones del diseño para detectar indicios de vulnerabilidades de seguri-

dad. Las soluciones SAST analizan una aplicación desde “dentro hacia fuera” en un
estado reposo, i.e., cuando no se está ejecutando.
• SDLC – Ciclo de vida de desarrollo software.
• Seguridad de la Arquitectura – Una abstracción del diseño de una aplicación que
identifica y describe dónde y cómo se utilizaran los controles de seguridad, además
de la ubicación y sensibilidad de los datos tanto del usuario como de la aplicación.
• Configuración de Seguridad – La configuración en tiempo de ejecución de una
aplicación que afecta a la forma en que se utilizan los controles de seguridad.
• Control de Seguridad – Una función o componente que realiza un chequeo de
seguridad (por ejemplo, una verificación del control de acceso) o que cuando es
invocado produce un evento de seguridad (por ejemplo, al generar un registro de
auditoría).
• Inyección SQL (SQLi) – Una técnica de inyección de código utilizada para atacar
aplicaciones basadas en datos, en la que se insertan instrucciones SQL maliciosas
en un punto de entrada.
• Autenticación SSO – La Autenticación de inicio de sesión único (SSO, por sus si-
glas en inglés) se produce cuando un usuario inicia sesión en un cliente y luego se
conecta desde otros servicios automáticamente, independientemente de la plata-
forma, tecnología o dominio que esté utilizando el usuario. Por ejemplo, un inicio de
sesión en Google dará acceso automáticamente a los servicios de YouTube, Drive y
Gmail.
• Modelado de Amenazas – Una técnica que consiste en desarrollar arquitecturas
de seguridad cada vez más perfeccionadas para identificar agentes de amenazas,
zonas de seguridad, controles de seguridad e importantes activos técnicos y empre-
sariales.
• Seguridad en la Capa de Transporte (TLS) – Protocolos criptográficos que pro-
porcionan seguridad en las comunicaciones a través de Internet.
• URI y URL – Un Identificador Uniforme de Recursos (URI) es una cadena de carac-
teres que se utiliza para identificar un nombre o un recurso web. Un Localizador
Uniforme de Recursos (URL) se utiliza a menudo como referencia a un recurso.
• Pruebas de Aceptación de Usuario (UAT) – Tradicionalmente un entorno de prue-
bas que se comporta como el entorno de producción donde se realizan todas las
pruebas de la aplicación antes de su puesta en marcha.
• Verificador – La persona o equipo que está revisando una aplicación usando los
requerimientos del MASVS de OWASP.
• Lista Blanca – Una lista de datos u operaciones permitidas, por ejemplo, una lista
de caracteres que permiten realizar la validación de la entrada.
• Certificado X.509 – Un certificado X.509 es un certificado digital que utiliza el
estándar internacional de infraestructura de clave pública (PKI) X.509 ampliamente
aceptado para verificar que una clave pública pertenece a la identidad de usuario,
46
dispositivo o servicio contenida en el certificado.
47
Apéndice B: Referencias
Los siguientes proyectos de OWASP serán probablemente de utilidad para los usuarios
de este estándar:
• Proyecto de Seguridad Móvil de OWASP - https://owasp.org/www-project-mobile-

security/
• Guía de Pruebas de Seguridad Móvil OWASP - https://owasp.org/www- project-
mobile-security-testing-guide/
• Top 10 de Riesgos Móviles de OWASP - https://owasp.org/www-project-mobile-top-
10/
• Ingeniería Inversa y Prevención de Modificación de Código de OWASP - https://wiki
.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Preve
ntion_Project
También los siguientes sitios web serán probablemente de utilidad para los usuarios de
este estándar:
• Enumeración de debilidades comunes de MITRE - http://cwe.mitre.org/

• Consejo de Normas de Seguridad PCI - https://www.pcisecuritystandards.org
• Estándar de seguridad de datos PCI (DSS) v3.0 Requerimientos y procedimientos de
evaluación de la seguridad https://www.pcisecuritystandards.org/documents/PCI_D
SS_v3.pdf
48
Changelog
V1.3 - 13 May 2021
We are proud to announce the introduction of a new document build pipeline, which is
a major milestone for our project. The build pipeline is based on Pandocker and Github
Actions. This significantly reduces the time spent on creating new releases and will also
be the foundation for the OWASP MSTG and will be made available for the OWASP ASVS
project.
Changes
• 4 more translations are available, which are Hindi, Farsi, Portuguese and Brazilian
Portuguese
• Added requirement MSTG-PLATFORM-11
Special Thanks
• Jeroen Willemsen for kick-starting this initiative last year!

• Damien Clochard and Dalibo for supporting and professionalizing the build pipeline.
• All our Hindi, Farsi, Portuguese and Brazilian Portuguese collaborators for the exce-
llent translation work.
V1.2 - 7 de marzo 2020 - Release Internacional
Los siguientes cambios forman parte de la versión 1.2:
• El MASVS ha sido traducido al chino simplificado.

• El título ha sido cambiado en la portada del MASVS.
• Todas las referencias CWE y Mobile Top 10 han sido eliminadas de la MSTG y han
sido integradas a las referencias existentes en el MASVS.
V1.2-RC - 5 de octubre de 2019 - Pre-release
• ¡Ya somos flagship!

• Requisitos MSTG-STORAGE-1 modificado para ser más extricto.
• Añadidos los requisitos MSTG-STORAGE-13, MSTG-STORAGE-14 y MSTG-STORAGE-
15 centrados en la protección de datos.
49
• Actualizado el requisito MSTG-AUTH-11 para preservar información contextual.

• Actualizado el requisito MSTG-CODE-4 para cubrir más allá de la depuración.
• Añadido el requisito MSTG-PLATFORM-10 para incrementar la seguridad al usar Web-
Views.
• Añadido el requisito MSTG-AUTH-12 para recordar a los desarrolladores que deben
de implementar medidas de autorización, especialmente en aplicaciones multi usua-
rio.
• Descripción mejorada sobre como usar el MASVS dado una evaluación de riesgo.
• Añadida más descripción sobre contenidos de pago.
• Añadido el requisito MSTG-ARCH-11 incluyendo una política de divulgación respon-
sable para aplicaciones MASVS-L2.
• Añadido el requisito MSTG-ARCH-12 informando a los desarrolladores que las corres-
pondientes leyes internacionales de privacidad deberían de ser seguidas.
• Consolidado el estilo de referencias en la versión inglesa.
• Añadido el requisito MSTG-PLATFORM-11 para combatir el espionaje mediante tecla-
dos de terceros.
• Añadido el requisito MSTG-MSTG-RESILIENCE-13 para impedir el eavesdropping en
aplicaciones.
V1.1.4 - 4 de julio de 2019 - Summit edition
Los siguientes cambios forman parte de la versión 1.1.4:
• Todos los problemas de markdown arreglados.

• Versiones francesa y española actualizadas.
• Changelog traducido al chino (ZHTW) y al japonés.
• Verificación automática de sintáxis de markdown y accesibilidad de URLs.
• Categorías añadidas a cada requisito. Èstas serán usadas en futuras versiones de la
MSTG para encontrar recomendaciones y test cases con más facilidad.
• Tamaño del repositorio reducido y Generated añadido al .gitignore.
• Añadidos Código de Conducta y Guía de Contribución.
• Plantilla para Pull-Requests añadida.
• Actualizada la sincronización del repositorio con el servicio de Gitbook hosting.
• Scripts de generación de XML/JSON/CSV actualizados para todas las traducciones.
• Prólogo traducido al chino (ZHTW).
V1.1.3 - 9 de enero de 2019 - Pequeñas correcciones
• Requisito 7.1 corregido en la traducción al español.

• Nueva disposición de los traductores en los agradecimientos.
50
V1.1.2 - 3 de enero de 2018 - Patrocinio e internacionalización
• Añadido agradecimiento a los compradores del libro electrónico (e-book).

• Link de “falta de autenticación” añadido y link de “autentificación rota” actualizado
en V4.
• Requisitos 4.7 y 4.8 corregidos en la versión inglesa.
• ¡Primer release incluyendo internacionalización!
– Correcciones en la traducción al español. Ahora la traducción está sincronizada

con la versión en inglés (1.1.2).
– Correcciones en la traducción al ruso. Ahora la traducción está sincronizada con
la versión en inglés (1.1.2).
– ¡Corregido el primer release en chino (ZHTW), francés, alemán y japonés!
• Documento simplificado para facilitar la traducción.

• Añadidas instrucciones para poder hacer releases automáticos.
V1.1.0 - 14 de julio de 2018
• Requisito 2.6 “Se desactiva el portapapeles en los campos de texto donde se maneja
información sensible.” eliminado.
• Requisito 2.2 “No se debe almacenar información sensible fuera del contenedor de
la aplicación o del almacenamiento de credenciales del sistema.” añadido.
• Requisito 2.1 reescrito como “Las funcionalidades de almacenamiento de creden-
ciales del sistema son utilizadas para almacenar la información sensible, como la
información personal, credenciales del usuario y claves criptográficas.”
V1.0 - 12 de enero de 2018
• Requisito 8.9 eliminado por similitud con el 8.12.

• Requisito 4.6 generalizado.
• Correcciones menores (errores ortográficos, etc.).
51

OWASP - MASVS-v1 4 2-Es

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

OWASP - MASVS-v1 4 2-Es

Cargado por

Copyright:

Formatos disponibles

(Spanish Translation)

Version v1.4.2 20 de enero de 2022

Estándar de Veriﬁcación de Seguridad de Aplicaciones Móviles 12

V1: Requisitos de Arquitectura, Diseño y Modelado de Amenazas 20

V2: Requerimientos de Almacenamiento de datos y Privacidad 23

V3: Requerimientos de Criptografía 27

V4: Requerimientos de Autenticación y Manejo de Sesiones 29

V5: Requerimientos de Comunicación a través de la red 32

V6: Requerimientos de Interacción con la Plataforma 34

Requerimientos de Veriﬁcación de Seguridad . . . . . . . . . . . . . . . . . . 34

V7: Requerimientos de Calidad de Código y Conﬁguración del Compilador 37

V8: Requerimientos de Resistencia ante la Ingeniería Inversa 40

Con el tiempo, la industria ha conseguido un mejor control del panorama de amenazas

Por lo tanto, un estándar de seguridad para aplicaciones móviles debe centrarse en la

aspectos que requieren una cuidadosa consideración.

• Proveer requerimientos para arquitectos y desarrolladores de software que buscan

• Clariﬁcar el rol de los mecanismos de protección de software en la seguridad móvil

Somos conscientes de que es imposible lograr un consenso del 100% en la industria. No

Por Bernhard Mueller

Bienvenido al Estándar de Veriﬁcación de Seguridad de Aplicaciones Móviles (MASVS). El

El MASVS es la culminación del esfuerzo de la comunidad y la retroalimentación con la

Las cuentas se pueden crear en la siguiente URL: https://owasp.slack.com/join/shared_i

Líderes del proyecto Autor Colaboradores y revisores

Idioma Traductores y revisores

Alemán Rocco Gränitz, Sven Schleier (revisor)

Chino Bob Peng, Harold Zang, Jack S

Coreano Youngjae Jeon, Jeongwon Cho, Jiyou Han, Jiyeon Sung

Español Martin Marsicano, Carlos Holguera

Francés Romuald Szkudlarek, Abderrahmane Aftahi, Christian Dong (revisor)

Japonés Koki Takeyama, Riotaro Okada (revisor)

Persa Hamed Salimian, Ramin Ateﬁnia, Dorna Azhirak, Bardiya Akbari,

Portugués Mateus Polastro, Humberto Junior, Rodrigo Araujo, Maurício Ariza,

Idioma Traductores y revisores

Ruso Gall Maxim, Eugen Martynov, Chelnokov Vladislav (revisor), Oprya

Este documento comenzó como un fork del Estándar de Veriﬁcación de Seguridad de

OWASP Bay Area Chapter

Estándar de Veriﬁcación de Seguridad de

El MASVS se puede utilizar para establecer un nivel de conﬁanza en la seguridad de las

• Uso como una métrica - Proporciona un estándar dirigido tanto a desarrolladores

Modelo de Seguridad para una Aplicación Móvil

El MASVS deﬁne dos niveles de veriﬁcación de seguridad (MASVS-L1 y MASVS-L2), así

El cumplimiento de los requerimientos de MASVS-L1 dará como resultado una aplicación

I: Aunque recomendamos implementar los controles MASVS-L1 en toda apli-

II: Los controles de protección de software listados en MASVS-R y descritos en

Estructura del Documento

• Categoría de los requerimientos: MASVS-Vx, p. ej. MASVS-V2: Requerimientos de

Niveles de Veriﬁcación Detallados

MASVS-L1: Seguridad Estándar

MASVS-L2: Defensa en Profundidad

MASVS-R: Resistencia contra la Ingeniería Inversa y la Manipulación

La aplicación cuenta con el nivel de seguridad especíﬁco para la aplicación y también

En resumen, los siguientes tipos de veriﬁcación están disponibles:

Las diferentes combinaciones reﬂejan diferentes grados de seguridad y resistencia. El ob-

de seguridad MASVS-L2, como la autenticación de doble factor por razones de usabili-

Cómo Elegir el Tipo de Veriﬁcación

La implementación de los requisitos del nivel MASVS-L2 aumenta la seguridad, pero al

• Industria de la Salud: aplicaciones móviles que almacenan información personal

• Sector Financiero: Aplicaciones que permiten el acceso a información altamente sen-

en MASVS-R se pueden utilizar para incrementar el esfuerzo necesario para obtener

• Industria Financiera: aplicaciones de banca móvil que permiten al usuario mover

• Todas las aplicaciones que contengan “compras en la aplicación” deberían de prote-

Posición de OWASP en cuanto a Certiﬁcaciones MASVS y Marcas de

Ninguna certiﬁcación, marca de garantía o conﬁanza actualmente existente ha sido exa-