OWASP TOP 10 (V): Falsificación de petición en sitios cruzados (CSRF)

Llegamos con esta entrada al ecuador de la lista de OWASP, tras el repaso a las cuatro primeras vistas en entradas anteriores (I, II, III, IV). En esta ocasión, el artículo del top 10 del catálogo de vulnerabilidades de OWASP del año 2010 se basa en el riesgo conocido como Cross Site Request Forgery, CSRF, que en castellano tiene la difícil traducción que podemos leer en el título de esta entrada. Este riesgo no aparecía recogido en la lista del año 2004, sin embargo en 2007 apareció en quinto lugar, posición que mantiene en esta nueva clasificación de riesgos del año 2010.

Las vulnerabilidades relacionadas con la falsificación de petición en sitios cruzados permiten a un atacante la posibilidad de enviar una petición a una aplicación Web vulnerable ejecutando una acción a través de la víctima. 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 dispone de un conjunto de puntos bonificables que puede transferir a otros usuarios de la propia aplicación a través de un formulario que ejecuta una acción del siguiente tipo:

http://owasp.s2grupo.es/catalog/transfer.jsp?amount=4815&user=162342

Una vez recibida en el servidor, se le muestra la cantidad a transferir, el identificador del usuario y realiza el traspaso de puntos.

Veamos a continuación cómo un atacante puede aprovechar esta vulnerabilidad.Sea un usuario de nuestra aplicación de catálogo que accede para visualizar la información de los artículos de una determinada categoría, y realiza la autenticación en la aplicación de catálogo.

La representación simbólica de esta acción puede visualizarse en la imagen siguiente:

Una vez autenticado abre una nueva pestaña en su navegador favorito, por lo que mantiene la sesión abierta con nuestra aplicación de catálogo, y se dispone a buscar un artículo que desea comprar en otra de sus páginas preferidas competencia de nuestro catálogo, sin saber que este nuevo portal incorpora código malicioso.

De forma esquemática, la situación podría representarse de la siguiente forma:

Una vez el site malicioso recibe la petición, envía en la respuesta a dicha petición pero contiene parte de código malicioso que permite aprovechar la vulnerabilidad de CSRF. Esta situación podría representarse de la siguiente forma:

Esta respuesta podría ser a través de un elemento iframe, un formulario oculto, una ventana con tamaño diminuto o una imagen, por ejemplo. En esta situación en concreto utilizaremos una imagen para demostrar el tipo de vulnerabilidad que estamos explicando y supondremos que el resultado de la petición al segundo servidor con código malicioso devuelve una página HTML completa en la que nos encontramos el siguiente elemento:

<img src=”http://owasp.s2grupo.es/catalog/transfer.jsp?amount=4815&user=ID_MALICIOSO» height=»0″ width=»0″ />

El navegador del usuario, cuando recibe la respuesta del segundo servidor, construye el árbol DOM para representar la página que se le ha retornado y detecta que debe solicitar una imagen a nuestro catálogo, por lo que ejecuta automáticamente esta acción y, dado que dispone de una sesión abierta con nuestro servicio de catálogo, envía junto a la petición las credenciales de usuario autenticado de la forma:

http://owasp.s2grupo.es/catalog/transfer.jsp?amount=4815&user=ID_MALICIOSO»

La situación descrita puede ser representada mediante el siguiente diagrama:

De esta forma, nuestro servidor de catálogo recibe una petición para realizar una transferencia con un usuario autenticado y ejecuta la acción transfiriendo a la cuenta de puntos del usuario malicioso la cantidad indicada de forma oculta al usuario.

Como se ha mostrado, para que esta vulnerabilidad sea efectiva es necesario que la víctima se encuentre autenticada en nuestra aplicación, ya que en caso de que no lo esté, el servidor recibirá una petición de transferencia sin sesión válida, y asumiendo que la gestión de sesiones se realiza de forma correcta, solicitará al usuario su autenticación. Sin embargo, esta acción no será detectada por parte del usuario puesto que no visualizará la información al encontrarse ésta oculta.

Con el fin de evitar que nuestras aplicaciones sean vulnerables a este tipo de ataque, se recomienda el uso de testigos aleatorios en las peticiones al servidor, de forma que se valide en el servidor que el valor enviado coincide con el valor asignado a dicho formulario en la sesión del usuario. De esta forma, aunque se acceda al sitio web malicioso, cuando intente ejecutar la petición, el servidor retornará un error puesto que el testigo no coincide con el esperado.

Hasta aquí todo lo referente a las vulnerabilidades de falsificación de petición en sitios cruzados, de momento. Como saben, 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, o no les ha quedado clara la explicación, no tienen más que indicarlo en los comentarios y estaremos encantados de ampliar la información.

Con esta entrada nos despedimos hasta el próximo martes, por lo que pasen un buen fin de semana y tengan cuidado con la carretera.

Trackbacks

  1. […] OWASP TOP 10 (V): Falsificación de petición en sitios cruzados (CSRF) […]