Los 10 más importantes riesgos de seguridad de las apps móviles según Mobile Web Security (OWASP).

Ver también

Informe Anual de Estado de Seguridad de Aplicaciones móviles: Percepción vs. Realidad

Partiendo de la premisa de que la seguridad total de un sistema informático no existe, al es necesario tener en cuenta que el riesgo no puede eliminarse completamente, pero puede reducirse. Podríamos afirmar que un sistema es seguro si cumple las expectativas en un contexto dado. OWASP Mobile Security Project es un recurso centralizado destinado a proporcionar a los desarrolladores y equipos de seguridad los recursos que necesitan para crear y mantener aplicaciones móviles seguras

El test de seguridad de OWASP se divide en 10 sub categorías:

✔ Recopilación de Información
✔ Pruebas de gestión de la configuración
✔ Pruebas de la lógica de negocio
✔ Pruebas de Autenticación
✔ Pruebas de Autorización
✔ Pruebas de gestión de sesiones
✔ Pruebas de validación de datos
✔ Pruebas de denegación de Servicio
✔ Pruebas de Servicios Web
✔ Pruebas de AJAX

M1 – uso inadecuado de la plataforma

Esta categoría cubre el uso indebido de una característica de la plataforma o el no uso de los controles de seguridad de la plataforma. Puede incluir intentos de Android, permisos de plataforma, uso indebido de TouchID, o algún otro control de seguridad que sea parte del sistema operativo móvil. Hay varias maneras en que las aplicaciones móviles pueden experimentar este riesgo.

M2 – Almacenamiento de datos inseguros

Esta nueva categoría es una combinación de M2 ​​+ M4 de Mobile Top Ten 2014. Esto cubre el almacenamiento inseguro de datos y fugas de datos no deseados.

M3 – Comunicación Insegura

Esto cubre las versiones incorrectas del SSL, la negociación débil, la comunicación del texto claro de los activos sensibles, etc.

M4 – Autenticación Insegura

Esta categoría captura las nociones de autenticación del usuario final o gestión de sesión incorrecta. Esto puede incluir:

• No identificar al usuario en absoluto cuando sea necesario
• No mantener la identidad del usuario cuando se requiere
• Debilidades en el manejo de sesiones

M5 – Criptografía insuficiente

El código aplica la criptografía a un activo de información sensible. Sin embargo, la criptografía es insuficiente de alguna manera. Además, si la aplicación no utiliza la criptografía en absoluto cuando debería, probablemente pertenezca a M2. Esta categoría es para los problemas donde se intentó la criptografía, pero no se realizó correctamente.

M6 – Autorización Insegura

Esta es una categoría para capturar cualquier fallo en la autorización (por ejemplo, decisiones de autorización por parte del cliente, navegación forzada, etc.). Es distinto de los problemas de autenticación (por ejemplo, inscripción de dispositivos, identificación de usuarios, etc.). Si la aplicación no autentifica a los usuarios en absoluto en una situación en la que debería (por ejemplo, conceder acceso anónimo a algún recurso o servicio cuando se requiera acceso autenticado y autorizado), se trata de un error de autenticación y no un error de autorización.

M7 – Calidad del código del cliente

Esta fue la «Decisiones de Seguridad a través de entradas no confiables. Est decir, la captura de todos los problemas de implementación a nivel de código en el cliente móvil. Esto es distinto de los errores de codificación del servidor. Esto capturaría cosas como desbordamientos de búfer, vulnerabilidades de cadena de formato y varios otros errores de nivel de código donde la solución es reescribir algún código que se esté ejecutando en el dispositivo móvil.

M8 – Código de manipulación

Esta categoría cubre parches binarios, modificación de recursos locales, enganches de métodos, swizzling de métodos y modificación de memoria dinámica. Una vez que la aplicación se instala en el dispositivo móvil, el código y los recursos de datos quedan allí. Un atacante puede modificar directamente el código, cambiar dinámicamente el contenido de la memoria, cambiar o reemplazar las API del sistema que utiliza la aplicación o modificar los datos y recursos de la aplicación. Esto puede proporcionar al atacante un método directo de subvertir el uso previsto del software para el beneficio personal o monetario.

M9 – Ingeniería inversa

Esta categoría incluye el análisis del núcleo binario final para determinar su código fuente, bibliotecas, algoritmos y otros activos. Software como IDA Pro, Hopper, otool, y otras herramientas de inspección binaria dan al atacante una visión del funcionamiento interno de la aplicación. Esto puede usarse para explotar otras vulnerabilidades nacientes en la aplicación, así como para revelar información sobre los servidores back-end, las constantes criptográficas y cifras, y la propiedad intelectual.

M10 – Funcionalidad Extránea

A menudo, los desarrolladores incluyen la función de puerta trasera oculta u otros controles internos de seguridad de desarrollo que no están destinados a ser liberados en un entorno de producción. Por ejemplo, un desarrollador puede incluir accidentalmente una contraseña como comentario en una aplicación híbrida. Otro ejemplo incluye deshabilitar la autenticación de 2 factores durante la prueba.