OWASP MAS: el estándar para auditar la seguridad de aplicaciones móviles

Casi todas las empresas tienen una app móvil, pero auditar su seguridad sigue siendo, en muchos sitios, un proceso improvisado: cada uno mira lo que se le ocurre, sin un criterio común y sin saber si ha cubierto todo. OWASP MAS existe justo para eso: convierte la auditoría de apps móviles en una disciplina repetible, con un estándar que dice qué hay que comprobar y una guía que dice cómo comprobarlo.

En este artículo te explico qué es OWASP MAS, las tres piezas que lo componen, las categorías del estándar, cómo se aplica en una auditoría real, qué herramientas se usan y cómo enfocar este conocimiento en un contexto profesional, que es exactamente la forma de trabajar que enseñamos en nuestro curso de móvil.

En esta guía

• Qué es OWASP MAS
• Las tres piezas del proyecto
• Las categorías del MASVS
• Cómo se usa en una auditoría real
• Vulnerabilidades típicas por categoría
• Herramientas esenciales para auditar con OWASP MAS
• Android e iOS: el mismo estándar, distinta superficie
• De web a móvil: el puente natural
• OWASP MAS en bug bounty y entornos profesionales
• Por dónde empezar con OWASP MAS
• Preguntas frecuentes

Qué es OWASP MAS

OWASP MAS (Mobile Application Security) es el proyecto insignia de OWASP dedicado a la seguridad de aplicaciones móviles. No es una herramienta ni un curso: es el marco de referencia que la industria usa para evaluar si una app Android o iOS es segura, de forma consistente y completa.

Su gran virtud es que separa dos preguntas que mucha gente mezcla: qué hay que verificar y cómo se verifica. Y para unirlas, ha incorporado una tercera pieza que hace de puente. El flujo es este:

# El flujo de OWASP MAS
MASVS  →  MASWE  →  MASTG
 (qué)     (debilidades)   (cómo)

Las tres piezas del proyecto

MASVS: el estándar (el "qué")

El MASVS (Mobile Application Security Verification Standard) es la lista de requisitos de seguridad que una app debería cumplir. Cada requisito tiene un identificador claro (por ejemplo MASVS-STORAGE-1) y un criterio de cumple o no cumple. Es el documento que define el objetivo de la auditoría: la referencia contra la que mides la app.

MASWE: las debilidades (el puente)

El MASWE (Mobile Application Security Weakness Enumeration) es una incorporación más reciente y la que muchos artículos antiguos no mencionan. Es un catálogo de debilidades concretas y específicas de móvil que conecta cada requisito del MASVS con las pruebas que lo verifican. Hace de puente entre el "qué" del MASVS y el "cómo" del MASTG, igual que un mapa que dice "este requisito puede fallar de estas maneras".

MASTG: la guía de testing (el "cómo")

El MASTG (Mobile Application Security Testing Guide) es el manual técnico completo. Cubre desde el funcionamiento interno de los sistemas operativos móviles hasta ingeniería inversa avanzada, y contiene casos de prueba concretos (con identificadores como MASTG-TEST-0001) que te dicen qué buscar, qué herramientas usar y cómo reproducir el problema tanto en Android como en iOS. Es el sucesor del antiguo MSTG, renombrado en la reestructuración de 2023.

Y como apoyo práctico está el MAS Checklist, que enlaza cada control del MASVS con sus casos de prueba del MASTG. Es la referencia que tendrás abierta durante toda la auditoría y sirve también para fines de cumplimiento.

Las categorías del MASVS

El MASVS organiza sus requisitos en categorías. Conocerlas te da el mapa mental completo de lo que abarca una auditoría móvil seria:

Cómo se usa en una auditoría real

Aquí está la parte que de verdad importa. El error típico es coger una app y empezar a "trastear" sin método. Con OWASP MAS el proceso es sistemático y reproducible:

1. Partes de un requisito del MASVS que quieres verificar.
2. Miras en el MASWE las debilidades concretas asociadas a ese requisito.
3. Sigues los casos de prueba del MASTG para verificarlas, paso a paso.
4. Documentas el hallazgo con evidencia reproducible.

Un ejemplo clásico es MASVS-STORAGE-1 ("la app almacena los datos sensibles de forma segura"). El MASTG te indica que inspecciones el directorio de datos de la app y revises preferencias, bases de datos y caché en busca de información sensible en claro. Sobre una app propia, se ve así:

# MASVS-STORAGE sobre una app propia
# Acceder a los datos privados de la app (en un dispositivo de pruebas)
$ adb shell
$ run-as com.miapp.demo
$ cat shared_prefs/auth.xml
<map>
  <string name="session_token">eyJhbGciOiJIUzI1NiIs...</string>
  ← token de sesion guardado EN CLARO: incumple MASVS-STORAGE-1

Lo importante no es el comando, es el método: partes de un requisito, sabes qué debilidad buscas, la verificas con un caso de prueba definido y lo documentas con evidencia. Esa es exactamente la forma de trabajar de una auditoría profesional.

Vulnerabilidades típicas por categoría

Cada categoría del MASVS tiene un patrón de fallos que se repite en auditorías reales. Conocerlos de antemano te permite ir directamente a lo que más suele fallar. Recorremos las ocho en el orden del estándar.

MASVS-STORAGE: lo que más aparece

# Credenciales en SharedPreferences (Android)
$ adb shell run-as com.target.app
$ find . -name "*.xml" | xargs grep -i "password\|token\|secret\|key"

# Base de datos SQLite sin cifrar
$ find . -name "*.db" -o -name "*.sqlite"
$ sqlite3 app_data.db ".tables"
$ sqlite3 app_data.db "SELECT * FROM users;"

# iOS: ficheros en NSDocumentDirectory sin protección
$ objection -g com.target.app explore
$ ios filesystem ls

El patrón más común: tokens de sesión, contraseñas o PII guardados en SharedPreferences o en una base de datos SQLite sin cifrar. El desarrollador los pone ahí por comodidad, sin pensar que cualquier app con permisos de backup o un dispositivo con acceso root los expone por completo.

MASVS-CRYPTO: criptografía débil y claves mal gestionadas

# Algoritmos obsoletos en el código (tras descompilar con jadx)
Cipher.getInstance("DES")          ← cifrado obsoleto
Cipher.getInstance("AES/ECB/PKCS5Padding") ← modo ECB inseguro
MessageDigest.getInstance("MD5")   ← hash roto

# Clave incrustada directamente en el código
String key = "clave_secreta_incrustada_123";
  ← clave en el binario: cualquiera la extrae descompilando el APK

# Buscar claves y algoritmos en el código descompilado
$ grep -rniE "secretkey|aes|des|md5|cipher" ./sources/

El patrón típico en criptografía: algoritmos rotos (DES, MD5), modo de cifrado ECB o claves incrustadas directamente en el código. Una clave en el binario equivale a no tener cifrado, porque se extrae con solo descompilar la app.

MASVS-AUTH: autenticación validada solo en el cliente

# Validación de acceso solo en el cliente
# (la app comprueba el PIN localmente, sin confirmarlo en el servidor)
if (pinIntroducido.equals(pinGuardado)) {
    concederAcceso();
    ← se puede eludir modificando el binario
}

# Elusión de la autenticación biométrica con Frida
$ frida -U -f com.target.app -l biometric-bypass.js
# fuerza la respuesta de éxito sin huella válida

El fallo más grave de autenticación en móvil: validar la sesión o el PIN solo en el cliente, sin verificación en el servidor. Si la decisión de "acceso concedido" vive dentro de la app, se puede modificar. La regla de oro: toda autenticación y autorización debe confirmarse en el servidor.

MASVS-NETWORK: TLS mal configurado y certificate pinning ausente

# Interceptar tráfico con Burp Suite: configurar proxy en el dispositivo
# Si la app no implementa pinning, el tráfico aparece en claro

# Elusión del pinning con Frida (sobre app propia en entorno de pruebas)
$ frida -U -f com.target.app \
    -l ssl-pinning-bypass.js \
    --no-pause

# Network Security Config mal configurado (Android)
# res/xml/network_security_config.xml con:
<base-config cleartextTrafficPermitted="true">
  ← permite HTTP en claro: incumple MASVS-NETWORK-1

El error más habitual en red: la app acepta cualquier certificado TLS sin validarlo o tiene el network_security_config.xml configurado para permitir tráfico HTTP en claro. En apps bancarias o de salud esto es crítico.

MASVS-PLATFORM: WebViews y deep links mal gestionados

# WebView con JavaScript habilitado y acceso a ficheros locales
# En el código fuente (tras descompilar con jadx):
webView.getSettings().setJavaScriptEnabled(true);
webView.getSettings().setAllowFileAccess(true);
← combinación peligrosa: LFI via JavaScript en WebView

# Deep link sin validación de origen (AndroidManifest.xml)
<intent-filter>
  <data android:scheme="miapp" android:host="auth"/>
</intent-filter>
# Cualquier app puede abrir miapp://auth?token=ATTACKER_TOKEN

MASVS-CODE: dependencias vulnerables y manejo inseguro de datos

# Dependencias con vulnerabilidades conocidas
$ grep -A2 "dependencies" build.gradle
# cruzar las versiones con bases de datos de CVE (OSV, Snyk)

# Deserialización insegura de datos no confiables
ObjectInputStream in = new ObjectInputStream(datosNoConfiables);
Object obj = in.readObject();
  ← reconstrucción de un objeto controlado por el atacante

# Inyección SQL en un Content Provider
content://com.target.app/users?id=1' OR '1'='1

Aquí entran las vulnerabilidades clásicas de servidor trasladadas al cliente: dependencias sin actualizar con CVE conocidos, deserialización insegura de datos que controla el atacante e inyección SQL en componentes que aceptan entrada externa.

MASVS-RESILIENCE: detección de root/jailbreak y anti-tampering

# Verificar si la app detecta root (Android)
$ objection -g com.target.app explore
> android root disable

# Elusión de la detección de jailbreak en iOS con Frida
$ frida -U -f com.target.app \
    -l jailbreak-bypass.js

# Si la app no tiene controles de integridad,
# se puede reempaquetar el APK con código modificado:
$ apktool d target.apk
# modificar smali / inyectar código
$ apktool b target_modified/
$ jarsigner -keystore debug.keystore target_modified.apk androiddebugkey

MASVS-PRIVACY: identificadores persistentes y permisos excesivos

# Identificadores persistentes para seguimiento del usuario
Settings.Secure.ANDROID_ID
telephonyManager.getImei()   ← identificador persistente del dispositivo

# Permisos excesivos en el manifiesto (AndroidManifest.xml)
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>
<uses-permission android:name="android.permission.READ_CONTACTS"/>
  ← ¿los necesita la app para su función real?

# Datos personales (PII) enviados sin cifrar: capturar con Burp

La categoría más reciente. Revisa el uso de identificadores persistentes para seguimiento, los permisos que la app no necesita para su función y el envío de datos personales sin la debida protección. La privacidad ya es parte formal de una auditoría móvil seria.

Herramientas esenciales para auditar con OWASP MAS

El MASTG referencia las herramientas en cada caso de prueba. Estas son las que aparecen constantemente en una auditoría real, organizadas por función:

El entorno de pruebas mínimo

# Android: dispositivo o emulador con acceso root
# Opción 1: AVD con imagen de Google APIs (soporta root)
$ emulator -avd Pixel_6_API_33 -writable-system

# Opción 2: dispositivo físico con Magisk
# Permite Frida server y acceso completo al sistema de ficheros

# Instalar Frida server en el dispositivo
$ adb push frida-server /data/local/tmp/
$ adb shell "chmod +x /data/local/tmp/frida-server"
$ adb shell "/data/local/tmp/frida-server &"

# iOS: iPhone con jailbreak (palera1n / checkra1n para dispositivos compatibles)
# Instalar Frida desde Cydia/Sileo

Android e iOS: el mismo estándar, distinta superficie

OWASP MAS cubre las dos plataformas con el mismo marco, pero la superficie de ataque cambia bastante:

El estándar te da el mapa común; la habilidad está en saber traducir cada requisito a la realidad técnica de cada plataforma. Una buena auditoría móvil mira las dos.

De web a móvil: el puente natural

Hay un detalle que sorprende a quien empieza: una parte enorme de los fallos de una app móvil no están en la app, sino en su API. IDOR, autenticación rota, lógica de negocio, SQLi, SSRF... las mismas vulnerabilidades de servidor que ya conoces del hacking web, ahora detrás de una app.

La diferencia es el cliente. En web el cliente es un navegador con DevTools y toda la petición visible. En móvil el cliente es una app compilada, con lógica propia, que puede implementar certificate pinning, ofuscación del tráfico o validaciones locales que hay que entender y eludir antes de llegar a la API. Esa capa adicional es lo que se añade al conocimiento web que ya tienes.

Por eso el camino natural es llegar al móvil con base de web. Si vienes de explotación web a nivel experto con WXE, el salto a móvil con MXS es directo: reaprovechas todo lo que sabes de APIs y le sumas el lado específico del dispositivo (almacenamiento, plataforma, resiliencia, ingeniería inversa).

OWASP MAS en bug bounty y entornos profesionales

Saber OWASP MAS no es solo saber qué buscar: es saber cómo comunicar lo que encuentras. En un entorno profesional (pentest, bug bounty o auditoría interna) la diferencia entre un hallazgo que se toma en serio y uno que se descarta no está en la técnica: está en si el auditor puede mapear el problema a un estándar reconocido, demostrar impacto con evidencia reproducible y entregar algo que el cliente entienda.

Cómo los programas de bug bounty valoran los hallazgos móviles

Los programas de bug bounty maduros (HackerOne, Intigriti, Bugcrowd) cada vez incluyen apps móviles en scope. Lo que distingue un reporte que se paga de uno que se cierra como "informativo":

Categorías que más aparecen en bug bounty móvil

# Las categorías que generan más hallazgos válidos en programas reales:

# 1. MASVS-STORAGE: datos sensibles en claro
#    - SharedPreferences, SQLite, logs, backups
#    - Alta frecuencia, impacto variable según los datos expuestos

# 2. MASVS-NETWORK: ausencia o elusión del certificate pinning
#    - Permite interceptar y manipular tráfico API
#    - Suele ir encadenado con fallos en la API (IDOR, auth rota)

# 3. MASVS-PLATFORM: deep links y WebViews
#    - Open redirect, XSS en WebView, acceso a ficheros locales
#    - Impacto alto si el WebView tiene acceso a contenido autenticado

# 4. MASVS-AUTH: tokens expuestos o lógica de autenticación rota
#    - Validación de tokens solo en cliente, sin verificación server-side
#    - Muy frecuente en apps de fintech y salud

Por dónde empezar con OWASP MAS

• Lee el MASVS de principio a fin una vez. Es corto y te da el mapa completo.
• Elige una categoría (empieza por MASVS-STORAGE, la más accesible) y practica sus casos de prueba del MASTG sobre una app propia.
• Monta un entorno mínimo: Android con emulador con acceso root o dispositivo con Magisk, jadx para estático, Frida/Objection para dinámico, Burp para red.
• Usa el MAS Checklist como hoja de ruta para no dejarte nada.
• Documenta cada hallazgo como si fuera un informe real desde el primer día.

Preguntas frecuentes

¿Cuál es la diferencia entre MASVS, MASWE y MASTG?

El MASVS define los requisitos de seguridad (el qué), el MASWE cataloga las debilidades concretas asociadas (el puente) y el MASTG explica cómo verificarlas con casos de prueba (el cómo). Los tres forman el proyecto OWASP MAS.

¿Sirve OWASP MAS tanto para Android como para iOS?

Sí. El estándar es independiente de la plataforma; los casos de prueba del MASTG incluyen guía específica para cada una. Una auditoría completa cubre las dos.

¿Necesito saber hacking web antes de meterme en móvil?

Ayuda mucho. Buena parte de los fallos de una app viven en su API, que son las mismas vulnerabilidades de servidor del hacking web. Llegar al móvil con esa base hace el aprendizaje mucho más rápido y te permite encadenar fallos de cliente con fallos de servidor, que es donde está el impacto real.

¿OWASP MAS es una certificación?

No. Es un estándar y un conjunto de recursos abiertos y gratuitos. Es el marco que se usa para auditar, no un examen que se aprueba.

¿Necesito un dispositivo físico o sirve un emulador?

Para empezar, un emulador Android con imagen con acceso root es suficiente para la mayoría de pruebas: análisis estático, SQLite, SharedPreferences, WebViews, deep links. Para pruebas avanzadas de hardware (sensores, NFC, Bluetooth) o para iOS necesitas dispositivo físico. El MASTG especifica en cada caso de prueba si hay limitaciones con emulador.

¿Cuánto tiempo lleva dominar OWASP MAS?

Depende del nivel de entrada. Con base de hacking web puedes tener una auditoría Android básica funcional en semanas. El nivel profesional completo (Android + iOS, ingeniería inversa avanzada, elusión de controles modernos) requiere práctica sostenida con apps reales. El MXS está diseñado para llevar ese proceso de forma estructurada y con entorno de laboratorio propio.

¿Qué diferencia hay entre una auditoría con OWASP MAS y un pentest móvil genérico?

La cobertura y la reproducibilidad. Un pentest genérico suele encontrar lo que el auditor recuerda mirar ese día. Una auditoría con OWASP MAS tiene un checklist de 100+ controles que asegura que no se ha saltado ninguna categoría. Y cada hallazgo se puede referir directamente a un requisito del estándar, lo que facilita la comunicación con el cliente y la verificación posterior.

Referencias

• OWASP MAS: web oficial del proyecto de seguridad de aplicaciones móviles.
• OWASP MASVS: el estándar de verificación.
• OWASP MASTG: la guía de testing con casos de prueba.
• OWASP MASVS en GitHub: repositorio del estándar.