En esta ocasión, el cuarto artículo del top 10 del catálogo de vulnerabilidades de OWASP del año 2010 se basa en la vulnerabilidad conocida como referencia directa a objetos insegura. Anteriormente ya vimos los ataques relacionados con las vulnerabilidades XSS, de Inyección y de Robo de sesiones web.
La vulnerabilidad que les presentamos hoy no aparecía recogida en la lista del año 2004 puesto que se encontraba agrupada dentro de la categoría “Error de Controles de Acceso”, sin embargo en 2007 se tomó la decisión de separar dicha categoría por la importancia detectada en este tipo de vulnerabilidades, pasando a ocupar el cuarto lugar en la clasificación. En la nueva clasificación que estamos presentando continua siendo una de las vulnerabilidades más encontradas permaneciendo en la misma posición que en 2007, es decir, en cuarta posición.
Las vulnerabilidades relacionadas con la referencia directa a objetos permiten a un atacante la posibilidad de obtener manipular referencias internas de la aplicación para acceder a objetos sin autorización. Es decir, la aplicación desarrollada que es vulnerable a este tipo de ataques permite el acceso a ficheros, directorios o registros de la base de datos a partir, entre otros, de un enlace a una URL o a un parámetro en un formulario.
Veamos el siguiente ejemplo como demostración del tipo de situaciones en las que podemos encontrar un ataque de este tipo. Sea una aplicación que dispone de un frontal web en el que un usuario autenticado puede consultar una serie de artículos de una determinada categoría. Desde la página de cada artículo puede acceder a un documento en el que se encuentra un enlace para descargar las especificaciones de éste con una URL del tipo:
Una vez recibida en el servidor, obtiene el documento componiendo la ruta al fichero a partir de los parámetros enviados y se lo devuelve el fichero para que el usuario lo pueda descargar a su ordenador.
Un atacante de nuestra plataforma podría modificar la petición esperada que provocase que retornase cualquier fichero de configuración de la aplicación o del sistema operativo, por ejemplo, el fichero de conexión con la base de datos o el fichero de usuarios y contraseñas de la máquina que aloja este servicio (por utilizar un ejemplo clásico):
Para que esta vulnerabilidad sea efectiva, es necesario que la composición de la ruta al fichero se realice en el servidor sin realizar ningún tipo de comprobación respecto al nombre del documento que se desea descargar o la ruta a la cual se está accediendo.
Existe una variante de este tipo de vulnerabilidad que puede comprometer los mecanismos de seguridad de acceso a los datos de nuestra aplicación. Supongamos que nuestra aplicación de catálogo tiene definidos diferentes fabricantes que sólo permiten el acceso a sus especificaciones a los usuarios autenticados de su propia empresa. Estas especificaciones se muestran en modo de lista y se puede descargar cada una de ellas pulsando sobre su nombre obteniendo el fichero a partir de una URL semejante a la siguiente:
Un atacante de nuestra plataforma podría averiguar esta petición y obtener el fichero en cuestión independientemente de sus permisos puesto que este fichero se está publicando directamente en el servidor de aplicaciones, y únicamente la lógica de negocio es la que protege la disponibilidad de acceso a la información. Del mismo modo, supongamos que nuestra aplicación permite acceder a una pantalla en la que se visualizan los datos personales del usuario y desde ahí es posible la realización de modificaciones de esta información a través de una URL del tipo:
Una vez recibida en el servidor, obtiene la información del usuario y la presenta para su consulta y modificación en caso de ser necesario. Un atacante de nuestra plataforma podría modificar la petición esperada que provocase que retornase la información de cualquier otro usuario de la aplicación, vulnerando de esta manera la privacidad de la información y las reglas de negocio de la aplicación.
Con el fin de evitar que nuestras aplicaciones sean vulnerables a este tipo de ataque se debe evitar, en la medida de lo posible, la presentación al usuario de referencias directas a estos objetos. En caso de que no sea posible realizar esta modificación se deberán incorporar los mecanismos de seguridad necesarios para garantizar que dicho usuario dispone de permisos para acceder al recurso solicitado.
De esta forma, si se desea ofrecer acceso a un fichero, será más seguro realizarlo a través de una clave intermedia que permita garantizar que el usuario que intenta acceder al recurso dispone de los permisos suficientes, así como evitar la publicación directa de recursos a través del acceso directo mediante una URL que pueda ser predicha.
Y hasta aquí todo lo referente a las vulnerabilidades de referencia directa a objetos insegura, de momento. Como les hemos insistido en entradas anteriores, si quieren extenderse en la materia, más allá de los innumerables recursos de la red, pueden acudir a la web de OWASP, donde encontrarán mucha información de utilidad. Si desean que demos más detalles sobre alguna de las vulnerabilidades mostradas, no les ha quedado clara la explicación, o les gustaría que entrásemos más en profundidad, no tienen más que indicarlo en los comentarios y estaremos encantados de ampliar la información.
