Esta guía explica cómo funcionan los permisos "peligrosos" de Android desde el punto de vista de la seguridad: qué protegen, dónde pueden fallar y cómo probarlos y corregirlos de forma responsable en tu propia app. El objetivo no es evadir controles, sino entender el modelo de permisos lo bastante bien como para reducir la superficie de ataque, verificar tus componentes y cumplir los controles de OWASP MASVS. Todo lo que sigue asume que pruebas una app tuya en un entorno controlado, con tu consentimiento y sin datos reales de usuarios.
Respuesta rápida
Los permisos peligrosos de Android son permisos de tiempo de ejecución que protegen datos sensibles y que el usuario concede al usarse, según la documentación de Android. Desde la perspectiva de seguridad, los riesgos no vienen de que el permiso exista, sino de pedir de más, exponer componentes sin protección o confiar en un permiso mal definido. Se prueban de forma segura en un emulador o dispositivo de pruebas con tu propia app, usando análisis estático y dinámico, y se remedían siguiendo los controles de OWASP MASVS y las prácticas de MASTG.
¿Qué protege y qué API interviene?
El modelo de permisos de Android controla el acceso a datos y acciones sensibles mediante niveles de protección: normal, dangerous, signature y special. Los peligrosos (dangerous) son permisos de tiempo de ejecución: desde Android 6.0 (API 23), la app debe comprobar y solicitar el permiso antes de cada acceso, y el usuario decide. Las API implicadas son checkSelfPermission para comprobar, requestPermissions para pedir, y shouldShowRequestPermissionRationale para decidir si mostrar una explicación.
Entender esta API importa para la seguridad porque el fallo más común no es un "bypass" mágico, sino asumir que un permiso está concedido cuando no lo está, o pedirlo tan pronto que el usuario no entiende por qué. La siguiente tabla resume los niveles de protección y su riesgo típico.
| Nivel de protección | Quién lo concede | Riesgo típico |
|---|---|---|
| normal | El sistema al instalar | Bajo, pero suma superficie si sobra |
| dangerous (tiempo de ejecución) | El usuario, al usarse | Acceso a datos sensibles si se abusa |
| signature | Solo apps con la misma firma | Peligroso si el protectionLevel es débil |
| special (appop) | El usuario en Ajustes | Acciones potentes, como dibujar encima |
Un permiso peligroso bien integrado se pide en el momento de la acción, se comprueba siempre antes de usar el dato, y degrada con elegancia si el usuario lo deniega. Esa disciplina, más que cualquier truco, es lo que reduce el riesgo real.
¿Dónde fallan los permisos? Condiciones de debilidad
Los problemas de permisos casi siempre nacen de decisiones de diseño, no de un truco del sistema. Las condiciones de debilidad más habituales son pedir más permisos de los necesarios, que amplían la superficie sin beneficio; exponer componentes como activities, services, receivers o providers con exported=true sin exigir un permiso, lo que permite que otra app los invoque; y definir permisos personalizados con un protectionLevel débil, de modo que cualquier app pueda obtenerlos.
Otras dos condiciones son más sutiles y conviene revisarlas en tu propia app. La re-delegación de permisos, o "confused deputy", ocurre cuando tu app tiene un permiso y expone una función que lo usa en nombre de otra app sin verificar quién llama. Y el engaño del diálogo de concesión mediante superposiciones, conocido como tapjacking, busca que el usuario conceda un permiso sin darse cuenta. Ninguna de estas es un fallo de Android en sí: son puntos que debes cerrar tú, y son exactamente lo que se comprueba en una prueba de seguridad responsable. Revisarlas de forma sistemática es más útil que buscar un fallo espectacular, porque son las que aparecen una y otra vez en apps reales.
¿Cómo probar los permisos de forma segura?
Prueba siempre sobre tu propia app y en un entorno aislado: un emulador o un dispositivo de pruebas dedicado, nunca uno personal ni una app ajena. Empieza por el análisis estático para inventariar lo declarado. Una herramienta como MobSF extrae del .apk o .aab los permisos, los componentes exportados y los permisos personalizados con su protectionLevel, de modo que ya tienes el mapa de la superficie sin ejecutar nada.
Después, con análisis dinámico, verifica el comportamiento en ejecución. Herramientas de instrumentación como Frida u Objection permiten observar cómo tu app comprueba y usa los permisos, y confirmar que un componente no responde sin el permiso esperado. La metodología de OWASP MASTG describe estas pruebas paso a paso. La regla de oro del entorno de pruebas es simple: consentimiento sobre lo que pruebas, aislamiento del resto, y ningún dato real de usuarios en el dispositivo de prueba.
Un flujo de prueba, paso a paso
Un flujo repetible ayuda a no olvidar nada y a comparar versiones. Primero, extrae el inventario con análisis estático: permisos declarados, componentes exportados y permisos personalizados con su nivel de protección. Segundo, asocia cada permiso peligroso con la función concreta que lo usa; si no puedes nombrar esa función, el permiso es candidato a eliminar. Tercero, revisa cada componente exportado y decide si debe serlo y con qué permiso lo proteges.
Cuarto, en el dispositivo de pruebas, comprueba en ejecución que un componente protegido no responde sin el permiso esperado y que la app maneja con elegancia una denegación del usuario. Quinto, documenta cada hallazgo junto con su control de OWASP correspondiente, y repite el flujo tras cada cambio importante. Este orden convierte una auditoría difusa en una lista concreta y verificable, que además sirve como evidencia si necesitas justificar el nivel de seguridad de la app.
¿Qué control de OWASP aplica?
Los permisos se enmarcan sobre todo en MASVS-PRIVACY, la categoría de privacidad del estándar OWASP MASVS, que promueve minimizar los datos y accesos que la app solicita. La guía de pruebas OWASP MASTG lo detalla en su entrada de permisos de app (MASTG-KNOW-0017 para Android) y en prácticas como MASTG-BEST-0052, "Restringir el acceso a los componentes de una app Android". Para la interacción entre componentes y con la plataforma también aplica MASVS-PLATFORM.
En la práctica, verificar tu app contra estos controles significa comprobar tres cosas: que declaras el mínimo de permisos, que tus componentes no quedan expuestos sin protección, y que cualquier permiso personalizado usa un nivel de protección adecuado. Estos controles convierten la idea abstracta de "pedir menos permisos" en una lista concreta de verificaciones que puedes marcar una por una.
Remediación recomendada
La remediación sigue el mismo orden que las debilidades: reducir, proteger y verificar. La tabla siguiente relaciona cada debilidad con su corrección y el control de OWASP correspondiente.
| Debilidad | Remediación | Control OWASP |
|---|---|---|
| Permisos peligrosos de más | Declarar y pedir solo el mínimo | MASVS-PRIVACY, MASTG-KNOW-0017 |
| Componente exportado sin permiso | Marcar exported=false o exigir un permiso | MASTG-BEST-0052 |
| Permiso personalizado con nivel débil | Usar protectionLevel signature | MASTG-BEST-0052 |
| Confused deputy o re-delegación | Verificar al llamante antes de actuar | MASVS-PLATFORM |
| Concesión por engaño (tapjacking) | Proteger diálogos sensibles frente a overlays | MASVS-PLATFORM |
Aplica estas correcciones y vuelve a analizar el build para confirmar que la superficie se redujo de verdad. La remediación no es un evento único: cada vez que añades una función o una librería, conviene repetir el inventario de permisos y componentes, porque una dependencia nueva puede reintroducir una debilidad que ya habías cerrado.
Cómo un escáner ayuda a auditar permisos
La forma más rápida de tener el inventario completo es analizar el build, no revisarlo a mano. Un análisis estático muestra todos los permisos peligrosos, los componentes exportados y los permisos personalizados, incluidos los que añaden las librerías sin que te des cuenta, y los relaciona con posibles configuraciones de riesgo.
Un escáner como PTKD.com analiza el .apk o .aab y devuelve un informe mapeado a OWASP MASVS que señala permisos excesivos, componentes expuestos y otras configuraciones de riesgo. Conviene ser honesto sobre su límite: un escáner automatiza el inventario y las señales, pero no reemplaza una prueba dinámica con Frida u Objection ni el criterio de decidir qué permisos necesita realmente tu app. Úsalo como el primer paso que te da el mapa de la superficie, y complétalo con pruebas manuales cuando el riesgo lo justifique. Ese reparto de tareas, la máquina para el inventario y la persona para el criterio, es lo que hace sostenible auditar permisos en cada versión sin depender de la memoria.
Puntos clave
- Los permisos peligrosos son permisos de tiempo de ejecución; el riesgo viene del diseño, no de que existan.
- Las debilidades típicas son pedir de más, exponer componentes sin permiso y permisos personalizados con nivel débil.
- Pruébalos sobre tu propia app en un emulador o dispositivo de pruebas, con análisis estático (MobSF) y dinámico (Frida u Objection).
- Aplican MASVS-PRIVACY y MASVS-PLATFORM, con MASTG-KNOW-0017 y MASTG-BEST-0052 como referencia.
- Empieza el inventario con un análisis del build en PTKD.com y remedia reduciendo, protegiendo y verificando.
