Recientemente OWASP (Open Web Application Security Project) ha lanzado la nueva versión de su Top 10 de los riesgos de seguridad más importantes en aplicaciones web, estos se clasifican de acuerdo con la prevalencia de ese riesgo especifico en las aplicaciones web expuestas en la actualidad, por lo que podemos decir que el riesgo A1 es más común que A2, y así sucesivamente. Vamos a hablar un poco sobre el riesgo que ocupa el primer puesto de este top y el por qué llego este lugar.

Como podemos ver, es una vulnerabilidad que sube del top 5 al top 1, el cual, a mi parecer es un cambio muy interesante y es un puesto bien merecido, ya que si bien, hoy en día existen una gran cantidad de controles que nos ayudan a detectar y corregir algunas de las vulnerabilidades presentadas en este top, esta vulnerabilidad es difícil de detectar por herramientas automatizadas y va más bien relacionada con la información que enviamos al usuario final. Esta vulnerabilidad consiste en que el usuario pueda acceder a recursos a los cuales no se encuentra autorizado, lo que puede conducir al acceso, modificación o destrucción de información a la que no tiene permitido acceder. Algunos de los ejemplos más comunes que podemos ver de esta vulnerabilidad pueden ser:

• Acceder a información de otros usuarios modificando la URL.
• Navegar la aplicación como si fuera otro usuario modificando cookies o sesiones que se encuentren en texto claro.
• Cuando la aplicación permite modificar el rol del usuario al en las solicitudes de inicio de sesión, o bien, en cualquier solicitud que realice la aplicación y así lograr una elevación de privilegios.
• Cuando una consulta al API envía información adicional a la que se le debe de mostrar al usuario.
• Cuando no se tiene una configuración correcta de CORS que permite accesos al API desde orígenes desconocidos.
• Navegar la aplicación sin haberse autenticado modificando valores en las consultas.
• Navegar por paginas a las cuales solo pueden acceder usuarios con privilegios utilizando nuestro usuario estándar.

Para entrar un poquito en contexto de a que se refiere veamos algunas demostraciones de esta vulnerabilidad.

A continuación, se solicita la información de un usuario a través de una consulta a la API, mostrándonos los siguientes atributos:

Aparentemente, esta consulta nos trajo los datos correctamente, sin embargo, si revisamos desde el inspector o desde un proxy intermedio, podemos ver que esta consulta nos trajo mas datos de los que esperábamos, por lo que comenzamos a caer en uno de los impactos de esta vulnerabilidad, la divulgación de información:

La consulta llama a un endpoint en “/profile/ 2342384”, que podemos ver que ahí se envía el “userId” del usuario el cual estamos revisando su información, sin embargo, veamos que pasa si enviamos el parámetro de otro usuario:+

Al enviar un valor distinto, podemos ver que nos trae información de otro usuario, por lo que vemos que ya estamos evadiendo los controles de acceso de la aplicación.

Eso se puede deber a muchas razones, sin embargo, una de las principales es un manejo incorrecto de las sesiones de los usuarios que navegan la aplicación, permitiendo acceder a la información de otros usuarios o a recursos a los que no estamos autorizados.

Este riesgo se presenta en un gran número de aplicaciones, pero ¿Por qué es el top 1 de este año?, hoy en día, múltiples aplicaciones web realizan consultas a través de un ORM (Object Relational Mapping), lo cual facilita las consultas que nuestra aplicación realiza a la base de datos, si bien, esta tecnología ha ayudado mucho a mitigar vulnerabilidades de inyección de código, los datos deben ser tratados y filtrados desde el backend posteriormente a la consulta, ya que, se acostumbra a enviar la información entregada en la consulta directamente al forntend sin haber filtrado únicamente los datos necesarios, por ejemplo, consultar la información de un usuario con un id, hacemos una consulta la cual nos traiga un objeto “usuario” que contenga el id proporcionado, solo queremos ver el nombre en la aplicación, sin embargo, enviamos el objeto que nos entregó el ORM con toda la información del registro de este usuario, que a simple vista solo se despliega el nombre, sin embargo, si interceptamos la consulta podremos ver que hay más datos, lo que es una divulgación de información. De igual manera, el que muchas aplicaciones estén migrando a REST API ha involucrado un nuevo manejo de sesiones, los cuales si no están bien configurados puede llevar a que podamos modificar las consultar para ver la información de otros usuarios. El uso de estas tecnologías no es malo, al contrario, son muy eficientes para nuestra aplicación, sin embargo, hay que implementarlas correctamente para prevenir riesgos.

¿Por qué es un riesgo silencioso para nuestra aplicación? Esta vulnerabilidad normalmente no es detectada por herramientas automatizadas de escaneo o controles de seguridad como IPS/IDS o WAF (Web Application Firewall), como ya mencionamos al principio, este riesgo tiene que ver con la información que enviamos en las consultas y como es consultada, así mismo, las modificaciones que realizamos en el API puede provocar nuevas divulgaciones de información en páginas que consulten al mismo enpoint, por lo que la mejor manera de prevenirlo es desarrollando nuestra API de tal manera que solo se envíe la información que se está consultando y estableciendo un correcto sistema de tokens y sesiones basado en roles.

Lic. José Eduardo Torres Torres – Consultor de Seguridad de Información