Seguridad en aplicaciones móviles y web con OWASP

Introducción

La seguridad digital es actualmente un punto al que hay que dedicar especial atención. Nos encontramos en continua conexión a la red, ya sea utilizando un ordenador o dispositivos móviles. Ambos permiten interactuar con Internet a través de:

• Páginas Web
• Aplicaciones instaladas

Los equipos de personas que se dedican al desarrollo estas aplicaciones tienen que tener esto en cuenta. Del mismo modo, las personas dedicadas a identificar posibles problemas y realizar auditorías de seguridad, necesitan poder tener una hoja de ruta para llevar un orden.

¿Qué sucede entonces? ¿Cada persona se crea sus propias guías? En los equipos de trabajo ¿la persona responsable implanta sus propias reglas?

Para que a nivel global se puedan seguir las mismas reglas aparece OWASP. Una organización sin ánimo de lucro que a continuación en este artículo conoceremos y veremos que puede ofrecernos y cómo ayudarnos.

Qué es OWASP

Las iniciales OWASP corresponden con “Open Web Application Security Project“. Puede visitarse la web oficial en el siguiente enlace.

Es un proyecto sin ánimo de lucro que tiene como finalidad mejorar la seguridad de las aplicaciones web, tanto el que es creado nuevo cómo el que ya está en uso. Esto lo realiza a través de recursos y herramientas libres para su uso.

Nota:
Cuando hablo de software no me refiero únicamente a herramientas que podemos instalar en nuestros dispositivos. También se incluyen las páginas Web. Esto es así porque detrás de las páginas existe software que permite mantenerlas y darnos acceso a ellas. Así como el propio lenguaje de programación en el que se desarrollen, pueden tener vulnerabilidades.

Una de las cosas principales que tiene este proyecto es la determinación de las vulnerabilidades más comunes que se encuentran en las aplicaciones. De esta forma se consiguen reunir y así ofrecer a profesionales y organizaciones los fallos más potenciales.

Para poder realizar esta clasificación OWASP utiliza la tabla que vamos a ver a continuación. Pero antes voy a explicar de qué campos se compone para entenderlo mejor:

• Agente de amenaza

  Depende de la aplicación específica tendrá una puntuación más o menos grave.

• Explotabilidad

  Corresponde a lo fácil o difícil que resulta poder explotar la vulnerabilidad. Es decir, conseguir aprovecharla para realizar alguna acción.

• Prevalencia de la vulnerabilidad

  Probabilidad de que la vulnerabilidad se encuentre en las aplicaciones. Esto quiere decir que algunas vulnerabilidades son propensas a existir en función de la aplicación.

• Detección de la vulnerabilidad

  Consiste el grado de dificultad que requiere detectar que ese tipo de vulnerabilidad existe en la aplicación.

• Impacto técnico

  Este concepto tiene que ver con el daño a nivel técnico que puede realizar un atacante aprovechando la vulnerabilidad. Por ejemplo:

  • Extracción de información sensible
  • Destrucción de datos
  • Denegación de servicio

• Impacto de negocio

  En función de la organización y como afecte al negocio tendrá una puntuación más o menos grave.

Aquí tenemos la tabla a la que hacía referencia anteriormente:

Nota:
Al mismo tiempo, estos datos nos ofrecen la capacidad de determinar donde son más inseguras las aplicaciones y los puntos que se deben prestar más atención. Tanto cuando se desarrolla software nuevo, cómo para revisar y auditar software ya en uso.

Teniendo en cuenta la tabla anterior y analizando una vulnerabilidad en particular, se puede obtener una puntuación que ofrece el nivel de riesgo que implica la dicha vulnerabilidad. Por ejemplo, la vulnerabilidad que está a la cabeza del listado que ofrece OWASP corresponde con la Inyección de código. ¿Por qué es esto así? A continuación, analizamos este riesgo teniendo en cuenta la tabla anterior.

Dejando a un lado las puntuaciones de Agente de amenaza e Impacto de negocio. Recordemos que esto depende de la aplicación y el negocio. Nos centramos en los otros cuatro conceptos.

La puntuación de un riesgo referente a Inyección de código se obtiene de la información anterior realizando las siguientes operaciones.

• Se obtiene la media de los tres primeros conceptos (explotabilidad, prevalencia de la vulnerabilidad y detección de la vulnerabilidad)
• Una vez obtenido este dato, se multiplica por la puntuación del Impacto técnico

De esta forma y tomando el ejemplo anterior, podemos comprobar que su puntuación es 8,0.

Nota:
El resultado se obtiene de la siguiente operación teniendo en cuenta las indicaciones anteriores.
((3 + 2 + 3) / 3) * 3

Para poder ampliar más información, es posible consultarla de forma detallada a través de los documentos oficiales creados por OWASP. Los dos siguientes enlaces corresponden con el repositorio del documento en inglés.pdf) y en español.

OWASP Mobile Security Project

En el punto anterior hemos visto que es y en que consiste OWASP, pero ¿qué es esto de OWASP Mobile Security Project?

OWASP sin más, se centra principalmente en una metodología relacionada con los riesgos existentes en aplicaciones web en general. Sin embargo, en este caso el foco son los nuevos dispositivos móviles.

Desde hace algún tiempo y cada vez más, disponemos de disponemos de dispositivos a los cuales se les pueden instalar aplicaciones. Aquí es donde entra OWASP Mobile Security Project. Enfocarse en los riesgos de seguridad de las propias aplicaciones y sistemas de estos dispositivos.

Se puede acceder directamente a la web oficial a través del siguiente enlace.

Para qué sirve OWASP

Una vez que hemos visto una introducción y explicación de en qué consiste OWASP, voy a pasar a describir que usos tiene toda la información aportada por esta organización.

El principal uso que tienen los documentos publicados por OWASP es su utilización como guías y metodología para tener en cuenta a la hora de realizar auditorías en aplicaciones. ¿Qué se consigue con ello? Fácil, chequear los riesgos más habituales y comprobar que no existen vulnerabilidades de este tipo. ¿Y si existen? Reportarlo para que el equipo de desarrolladores proceda a corregir lo antes posible el problema.

Otro uso importante que ofrecen los documentos de OWASP son utilizarlos como referencia en el proceso de desarrollo de aplicaciones nuevas. ¿De qué forma? Mediante los documentos de buenas prácticas ofrecidos por OWASP. Así se introducen dentro del Ciclo de Desarrollo Seguro (SDLC).

Una guía bastante completa para realizarlo la puedes encontrar en el siguiente enlace.

Aunque estamos pensando en todo momento en los beneficios que ofrece OWASP para ayudarnos a mejorar la seguridad. No hay que olvidar que esta información también es posible que sea utilizada por atacantes. De esta forma, tanto personas independientes cómo grupos pueden utilizarlo para realizar acciones ilegales e intentar acceder a nuestras aplicaciones.

OWASP Top 10

El concepto de OWASP Top 10 es sencillo de entender. Cómo se ha visto en puntos anteriores, desde OWASP se asignan y obtienen puntuaciones para los riesgos en aplicaciones. Pues el Top 10 no es más que un listado con los 10 riesgos de seguridad más críticos en aplicaciones.

A continuación, voy a explicar cada uno de ellos para entender en que afectan cada uno de estos riesgos.

A1 - Inyección

Las vulnerabilidades bajo el riesgo de inyección tienen que ver cuando los datos no son correctamente validados por la aplicación. De esta forma, un atacante puede utilizarlo para introducir código (inyectar).

Por ejemplo, piensa en una aplicación que utiliza una base de datos. Si la aplicación no es capaz de validar correctamente los datos que introduce el usuario, un atacante podría manipular la información que introduce para obtener datos sensibles, obtener usuarios, etc.

En este caso estaríamos ante una inyección SQL o también denominada SQLi (SQL injection).

A2 - Pérdida de Autenticación

La pérdida de autenticación está enfocada a que un atacante es capaz de comprometer la sesión de un usuario. Esto ocurre por una mala implementación del mecanismo utilizado para la gestión de sesiones.

Si los mecanismos no son seguros, un atacante puede hacerse con información de la sesión. Esto equivale exactamente a que el atacante tuviese usuario y contraseña. Por este motivo sería capaz de poder acceder a la aplicación como si fuese el usuario vulnerado.

Cómo se puede observar, podría conllevar a una suplantación de identidad.

A3 - Exposición de datos sensibles

La exposición de datos sensibles se puede entender sólo con su denominación. Consiste en que la aplicación no protege de forma correcta los datos. Por ejemplo, esto puede ocurrir si no se protege correctamente la comunicación entre cliente y servidor. En ocasiones ocurre que únicamente se utiliza cifrado mediante SSL/TLS en el proceso de identificación. Pero una vez dentro de la aplicación, los datos en la comunicación van sin cifrar. Por lo que estarían expuestos y sin protección.

A4 - Entidades externas XML (XXE)

Este riesgo entra en juego cuando se utilizan aplicaciones o servicios basados en XML. Lo que le da nombre a este riesgo son unas de las entidades que se pueden declarar en XML. Estas son denominadas entidades externas.

Si estas entidades pueden ser declaradas por los usuarios, entonces esta vulnerabilidad podría afectar a la aplicación.

A5 - Pérdida de control de acceso

Una forma sencilla de entender este riesgo es comenzando por saber que está relacionado con los permisos de los usuarios dentro de la aplicación. De esta forma, la aplicación no es capaz de realizar las comprobaciones necesarias para dar los accesos necesarios.

Es decir, imagina un usuario si ningún privilegio, únicamente tiene acceso a sus datos. Si esta vulnerabilidad existe en la aplicación, podría manipular el acceso y conseguir acceder a lugares que únicamente tiene acceso un administrador.

Cómo se puede observar, un usuario podría utilizarlo para acceder y manipular características de la aplicación. O incluso ver datos sensibles de otros usuarios. Esto dependerá del funcionamiento que tenga la aplicación.

A6 - Configuración de seguridad incorrecta

El riesgo por configuración incorrecta se define por sí mismo. Se refiere principalmente a que no solo la aplicación tiene que ser revisada. El sistema y los servicios que permiten que esa aplicación esté disponible, también deben tener una seguridad correcta. No puede dejarse todo por defecto, ya que eso es una mala práctica.

Por ejemplo, una aplicación web requiere de un servidor web. Este tiene que estar sobre un sistema operativo (Windows, Linux, …) y un servicio web (Apache, …). Estos deben tener una configuración de seguridad correcta.

Si la aplicación es muy segura, pero tiene agujeros de seguridad en estos otros focos, el resultado es que podemos tener vulnerabilidades y sufrir ataques por ellas.

A7 - Cross-Site Scripting (XSS)

El riesgo basado en XSS es similar al visto en primer lugar. En este caso, al igual que en el de Inyección, la vulnerabilidad es producida por un problema en la validación de datos de entrada. Pero en esta ocasión afecta directamente al sitio web. ¿Qué quiere decir esto? El código introducido se ejecuta sobre el navegador del usuario.

En el caso de la Inyección, se veía que el problema afecta directamente a la organización y sus servidores. En esta ocasión, el afectado es el usuario que accede a esta aplicación.

A8 - Deserialización insegura

Para entender la deserialización primero hay que conocer el concepto de serialización. A grandes rasgos no es más que el proceso que se realiza para convertir un objeto a un formato. Este formato puede ser por ejemplo XML, JSON, …

Cómo habrás adivinado, el concepto de deserialización es el proceso contrario. Por lo que la deserialización insegura consiste en que este proceso lo realiza mediante datos no confiables. Es decir, manipulados por algún usuario.

A9 - Componentes con vulnerabilidades conocidas

Cuando se realiza el desarrollo de aplicaciones, en algunas ocasiones hay que basarse en componentes. Esto implica la utilización por ejemplo de librerías.

Este riesgo va enfocado a estos componentes. Hay que validar que las librerías utilizadas sean las últimas versiones y sin vulnerabilidades conocidas. Si esto no es así, un atacante puede utilizar una vulnerabilidad incorporada en estos componentes.

En función del tipo de vulnerabilidad y donde se esté utilizando, el daño que puede ocasionar será más o menos grave.

A10 - Registro y monitoreo insuficientes

Para hablar de este riesgo hay que dirigirse a los conceptos de monitorización y registro de eventos por parte de la aplicación. Normalmente, una aplicación debe tener la capacidad de registrar los eventos que suceden en ella. Por ejemplo, un error en el inicio de sesión de un usuario.

Si esto no está correctamente configurado, no es posible tener una trazabilidad de lo que está ocurriendo en la aplicación. No dispondremos de ningún tipo de información, ni de funcionamiento correcto ni de problemas o funcionamiento incorrecto.

Es por este motivo que, en caso de estar recibiendo algún tipo de ataque o vulneración, no podremos ser conscientes y por lo tanto no se podrán tomar medidas para pararlo o analizarlo.

Continúa tu formación en Ciberseguridad

Para continuar formándote en tu camino hacia la ciberseguridad, no olvides visitar nuestros diversos cursos sobre esta temática, que podrás encontrar agrupados en la categoría de Cursos de Ciberseguridad.