Comprueba de manera sencilla si tu aplicación web es vulnerable a la Referencia Directa Insegura a Objetos con la OTG-AUTHZ-004

La prueba de seguridad OTG-AUTHZ-004 (Testing for Insecure Direct Object References) tiene como objetivo comprobar si está presente la vulnerabilidad de Referencia Directa Insegura  a Objetos, la cual se pone de manifiesto cuando una aplicación web provee acceso directo a recursos en base a las entradas suministradas por los usuarios sin una verificación correcta de autorización. En estos casos, la aplicación web no realiza los suficientes controles de seguridad y un atacante puede ser capaz de saltar las restricciones de autorización mediante el simple cambio de los valores de los parámetros enviados. El informe OWASP Top 10 incorpora esta vulnerabilidad dentro de los diez los riesgos más críticos que enfrentan las organizaciones.

Para la realización de esta prueba de seguridad es necesario determinar todos los puntos de entrada de la aplicación que usan datos suministrados por el cliente para referenciar directamente a recursos, ya sean almacenados en bases de datos, archivos de imágenes, documentos o código fuente, entre otros. El segundo paso consistiría en modificar los parámetros enviados para comprobar si es posible acceder a recursos asignados a otros usuarios y roles.

A continuación, explicaré cuales son los escenarios más comunes que pueden encontrarse en la realización de las comprobaciones de seguridad. Para las demostraciones, se emplearon aplicaciones web del proyecto OWASP BWA:

Valores de parámetros usados directamente como ID de bases de datos

Este primer escenario se presenta cuando se envía a la aplicación un identificador(ID) que responde a un objeto de la base de datos como puede ser una consulta, un registro, etc. La vulnerabilidad está presente cuando la aplicación web procesa directamente este ID sin revisar primer si el usuario está autorizado para acceder a la información. En la figura 1 se muestra como se envía en el cuerpo de una petición HTTP el parámetro userId, el cual ha sido manipulado para acceder a la información del usuario con ID=9. En su manifestación más evidente y común, puede preciarse los parámetros en la propia URL (Figura 2).

figura-1-manipulacion-del-userid-enviado-en-el-cuerpo-de-una-peticion-http

Figura 1. Manipulación del userId enviado en el cuerpo de una petición HTTP. Puede apreciarse a la derecha como la aplicación web responde un con código 200 y devuelve información vinculada a dicho userId. Elaboración propia.

Figura 2 - Manipulación del parámetro de URL userid.png

Figura 2. Manipulación del parámetro de URL userid para acceder a las imágenes subidas por los usuarios. Elaboración propia.

Valores de parámetros usados directamente para desarrollar una operación en el sistema

El segundo escenario aparece cuando los parámetros son usados además para ejecutar una operación en el sistema, por ejemplo, en la figura 3 (URL= http://192.168.56.104/peruggia/index.php?action=updel&pic_id=15) podemos apreciar que se usa el parámetro action para indicar que se desarrollará una acción de borrado, mientras que pic_id especifica el identificador de la imagen a borrar. Un atacante, por tanto, puede construir peticiones para borrar imágenes que otros usuarios han subido solo cambiando el valor de pic_id.

figura-3-los-parametros-de-la-url-envian-directamente-la-operacion-a-realizar

Figura 3. Los parámetros del hipervínculo envían directamente la operación a realizar sobre la imagen sin pasar por un filtro de autorización correspondiente. Elaboración propia.

 Valores de parámetros usados para acceder directamente a un archivo.

En estos casos, los parámetros enviados a la aplicación web contienen el nombre o un código de referencia a determinados archivos, el problema se manifiesta cuando el usuario manipula el valor del parámetro y la aplicación web le permite acceder a los archivos restringidos a sus roles o privilegios.

Es muy común encontrar este comportamiento en CMS mal configurados y aplicaciones web que manejan muchos archivos, sin embargo, como se ejemplifica en la figura 4, puede incluso servir para acceder a los archivos internos. En este ejemplo se muestra cómo puede especificarse el archivo phpinfo.php, siendo este cargado sin restricción alguna y exponiendo datos muy sensible del servidor web.

figura-4-valores-de-parametros-usados-para-acceder-directamente-a-un-archivo

Figura 4. Valores de parámetros usados para acceder directamente a un archivo. Elaboración propia.

Valores de parámetros usados directamente para acceder a funcionalidades de la aplicación.

Este último escenario tiene lugar cuando se utiliza un parámetro para acceder a las funcionalidades del sistema, por ejemplo http://foo.bar/accessPage?menuitem=12. Si no existe un adecuado mecanismo de autorización, un usuario puede acceder a funcionalidades que no están establecidas para su rol o privilegios en el sistema mediante la simple modificación de los valores del parámetro. En la figura 5 apreciamos otro ejemplo de este escenario.

figura-5-valores-de-parametros-usados-para-acceder-a-funcionalidades

Figura 5. Valores de parámetros usados para acceder a funcionalidades. Elaboración propia.

Hasta aquí he presentado los cuatro escenarios más comunes que son tratados en la OTG, es válido destacar que estos escenarios pueden estar segmentados y puede ser necesario manipular varias peticiones para llegar al mismo resultado. De igual modo, no deben ser analizados solamente los parámetros URL, en la figura 1 pudo apreciarse que también los parámetros enviados en el cuerpo de una petición POST o incluso las cookies, pueden contener referencias directas a objetos que pueden ser explotadas con facilidad.

Aunque esta entrada trata sobre problemas asociados a mecanismos de autorización, creo que es válido señalar que hay mecanismos para evitar que un atacante pueda predecir los valores de los parámetros asociados a los objetos de la aplicación web. Uno de los más sencillos es utilizar un valor hash o como mínimo un número pseudoaleatorio los cuales siempre serán mejor que la enumeración secuencial estilo imagen0001, imagen 0002, imagen 0003 o userID 1, userID 2.

Espero que te haya gustado la entrada y te pueda ayudar a fortalecer la seguridad en tu aplicación web. Yo por mi parte he disfrutado escribiéndola.

S4lud0s y h4st4 el próx1m0 p0st!!!

 

Anuncios

Un comentario en “Comprueba de manera sencilla si tu aplicación web es vulnerable a la Referencia Directa Insegura a Objetos con la OTG-AUTHZ-004

  1. Pingback: ¿Que es un ataque de tipo “Parameter Tampering” y como puede evitarse? | Behique Digital

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s