El Open Web Application Security Project (OWASP) es una organización mundial sin ánimo de lucro que publica con frecuencia información práctica sobre la seguridad de las aplicaciones. OWASP publicó el «Top 10 Mobile Risks», una lista dedicada a la protección de las aplicaciones móviles.
Las prácticas referenciadas abarcan las comunicaciones no seguras, la autenticación débil, la alteración de código, la ingeniería inversa, etc. Están clasificadas por explotabilidad, prevalencia, detectabilidad e impacto, y van acompañadas de directrices para los desarrolladores móviles que buscan proteger mejor sus aplicaciones. La concienciación de los desarrolladores en materia de seguridad es, por supuesto, uno de los elementos más determinantes.
Si no se identifican y corrigen antes de la puesta en producción, estas 10 vulnerabilidades pueden conducir al robo de datos, al fraude y dañar la reputación de la empresa afectada.
La solución de auditoría de seguridad de las aplicaciones móviles Pradeo Security identifica las vulnerabilidades OWASP, las clasifica según su nivel de severidad y ofrece recomendaciones para corregirlas.
M1 — Uso incorrecto de una plataforma
Las aplicaciones móviles se diseñan mediante entornos de desarrollo que ofrecen diversas funciones de seguridad para integrar en las aplicaciones. A veces los desarrolladores simplemente eligen no utilizar ninguna de esas funcionalidades, mientras que otros no siguen necesariamente la documentación y las configuran de forma torpe. En consecuencia, los fallos de seguridad se deben a menudo a la no utilización o a la mala implementación de los Intents de Android, del TouchID o el Keychain de iOS y de otras funcionalidades de seguridad. Para evitarlo, se aconseja a los desarrolladores seguir las buenas prácticas de programación y configurar de manera segura el lado servidor de las aplicaciones.
Ejemplo: Aplicaciones Citrix Worx
M2 — Almacenamiento de datos no seguro
Esta segunda categoría comprende las vulnerabilidades que pueden provocar fugas de datos. Desde el punto de vista de la seguridad, las aplicaciones no deben diseñarse para almacenar información sensible del lado del usuario final, como en las tarjetas SD, los archivos de aplicaciones o las bases de datos SQLite locales, sobre todo cuando no están cifradas. Además, esta categoría engloba también las malas prácticas, como escribir información sensible en los registros, en la memoria de las aplicaciones o en su código descompilado, algo que por supuesto nunca debería hacerse.
Ejemplo: Tinder
M3 — Comunicación no segura
Una aplicación móvil intercambia generalmente datos con varios servidores. Estas comunicaciones en la red pueden no estar cifradas ni correctamente autenticadas (handshake, versiones SSL incorrectas, negociación débil, comunicación en texto claro, etc.). En el caso de aplicaciones que tratan datos de carácter personal (bancos, salud, administraciones públicas…), estas vulnerabilidades representan un incumplimiento de las leyes de protección de datos. Por otro lado, cuando se encuentran en aplicaciones ligadas a objetos conectados (domótica, cámaras de seguridad, coches inteligentes…), pueden conducir a una toma de control.
Ejemplo: Relojes inteligentes defectuosos
M4 — Autenticación no segura
Esta categoría cubre la autenticación de los usuarios finales y la mala gestión de las sesiones. En las aplicaciones móviles, a diferencia de las aplicaciones web, los usuarios no están siempre conectados. Las aplicaciones móviles deben por tanto ser capaces de identificar al usuario y conservar su identificación a lo largo de toda su sesión, esté conectado o no.
Cuando los ciberdelincuentes identifican un esquema de autenticación inexistente o débil en las aplicaciones móviles, crean software malicioso que lo elude. Una autenticación de los usuarios con varios factores permite prevenir los accesos fraudulentos a los datos.
Ejemplo: Aplicación Android «Grab»
M5 — Criptografía insuficiente
El uso no seguro de la criptografía es frecuente entre las aplicaciones móviles que utilizan cifrado. Puede provenir de procesos defectuosos o de algoritmos de cifrado débiles por naturaleza. En ambos casos, un atacante puede explotar esta vulnerabilidad para descifrar los datos sensibles tratados por las aplicaciones. Para remediarlo, los desarrolladores deben asegurarse de aplicar normas criptográficas actuales y duraderas.
Ejemplo: Envío de datos personales sin cifrar
M6 — Autorización no segura
Tras autenticar a los usuarios, algunas aplicaciones conceden por defecto ciertas autorizaciones. Esas autorizaciones son a veces, erróneamente, demasiado amplias, lo que otorga a los usuarios derechos que no deberían tener. Si un ciberdelincuente obtiene los derechos privilegiados de una aplicación, puede acceder ilegalmente a información sensible, eliminar sistemas enteros o tomar el control de objetos conectados. El abanico de autorizaciones concedidas a los usuarios debe evaluarse antes de publicar las aplicaciones.
Ejemplo: Viper Smart Start
M7 — Calidad del código cliente
Esta categoría comprende vulnerabilidades como los desbordamientos de memoria intermedia (buffer overflow), las vulnerabilidades de cadena de caracteres formateada y otros errores a nivel de código que permiten la ejecución de código en los terminales móviles. En caso de desbordamiento de la memoria intermedia, por ejemplo, es posible escribir en zonas que contienen código ejecutable y sustituirlo por código malicioso, o sobrescribir de manera selectiva los datos relativos al estado del programa, provocando así un comportamiento que el desarrollador no había previsto originalmente. La mayoría de los problemas de calidad de código pueden resolverse aplicando buenas prácticas. Utilizar las mismas formas de código en toda la organización, hacerlas fáciles de comprender y acompañarlas de una documentación clara permite reducir ese riesgo.
Ejemplo: WhatsApp
M8 — Falsificación de código
La falsificación o tampering consiste en duplicar una aplicación, añadir una o varias puertas traseras a su código, volver a firmarla y publicarla en tiendas de aplicaciones de terceros. Las aplicaciones falsificadas suelen calificarse de clones malintencionados y apuntan generalmente a las aplicaciones bancarias y a las aplicaciones muy populares. Gracias a las puertas traseras, los atacantes son capaces de interceptar datos e incluso, a veces, de hacerse pasar por aplicaciones oficiales para comunicarse con los servidores de las empresas. Para prevenir este riesgo, los desarrolladores deben utilizar soluciones anti-tampering o dotar a sus aplicaciones de capacidades de detección del tampering.
Ejemplo: Postbank Finanzassistent
M9 — Ingeniería inversa
Para descomponer una aplicación, un atacante analiza su código binario con el fin de determinar su código fuente, sus bibliotecas, sus algoritmos, etc. Al proporcionar un conocimiento más profundo de la aplicación, esta técnica permite a los hackers identificar sus defectos y explotarlos más fácilmente. La ingeniería inversa puede provocar el robo de propiedad intelectual, de información sobre servidores, de claves criptográficas, etc. Para minimizar ese riesgo, los desarrolladores deben escribir un código complejo y utilizar métodos de ofuscación.
Ejemplo: Pokémon Go
M10 — Funcionalidad externa
Durante los ciclos de desarrollo, los desarrolladores integran a menudo puertas traseras o controles de seguridad en sus aplicaciones para detectar y corregir sus vulnerabilidades. Estas funcionalidades no deberían permanecer en el entorno de producción, pero a veces se olvidan accidentalmente. Cuando se identifican, pueden ser explotadas por los atacantes para acceder a datos sensibles u obtener derechos. Antes de publicar una aplicación, los desarrolladores deben revisar las configuraciones y desactivar los registros de depuración.
Ejemplo: Transferencia de archivos WiFi
