CSRF
Introducción
Cross Site Request Forgery (CSRF) es un tipo de ataque que intenta realizar una acción en un sitio donde la víctima tiene una sesión activa. Supongamos que el usuario previamente está logueado en el sitio web A, luego desde el sitio B llena un formulario y al enviarlo se realiza la petición hacia el sitio A, como el usuario ya estaba logueado se va a ejecutar la acción previamente pensada por el atacante. Por lo general, CSRF tiene la intención de modificar algún dato del usuario en el sitio objetivo, no para obtener información, por ejemplo modificar el email del usuario, modificar la clave, realizar una acción como una transferencia, entre otros.
¿Cómo funciona?
Este ataque se basa en que el servidor del sitio objetivo no distingue si la petición la realizó el usuario desde el propio sitio devuelto por el servidor o si se está realizando desde una web de terceros, ya que en cada petición se envían las credenciales que identifican a la sesión del usuario.
El atacante podría crear un formulario en la web www.soyelatacante.com que solicite algunos datos pero con el fin de que al enviar el formulario impacte sobre el sitio objetivo.
<form action=”https://sitioobjetivo.com/editar_email/” method=”POST”>
<input type=”hidden” name=”email” value=”soyelatacante@gmail.com” />
<input type=”text” name=”no-interesa” placeholder=”Ingrese un comentario” />
<input type=”submit” value=”Enviar” />
</form>
El usuario al enviar el formulario, en vez de estar enviando un comentario como es lo que parece, está modificando su email en sitioobjetivo.com.
Una forma de evitar que la víctima tenga que enviar el comentario, el atacante podría agregar el siguiente evento al body, esto permitiría que la víctima con solo entrar al sitio del atacante ya se ejecutaría el ataque:
<body onload="document.forms[0].submit()">
En caso de que la petición al servidor objetivo sea mediante el método GET, el atacante tiene más alternativas, una de ellas es agregar una imagen con el src manipulado de tal forma que el vector de ataque esté en esa url y la víctima solo visualizará una imagen dañada.
<img src=”https://sitioobjetivo.com/?nuevo_email=soyelatacante@gmail.com” width=”0” heigth=”0” />
Tener en cuenta que esta imagen podría ser agregada en sitios donde permiten comentarios html o incluso en un email.
Si bien hoy en día no es común encontrar peticiones GET que alteren los datos del lado del servidor como se recomienda en la sección 9.1.1 de RFC2616 (por convención los métodos GET y HEAD son definidos métodos seguros ya que no deberían realizar ninguna acción de importancia en el servidor), es totalmente factible que una petición de este tipo realice algo más que solo devolver datos.
Para que el ataque tenga efecto es necesario que el usuario tenga una sesión abierta en el sitio objetivo. Muchos sitios mantienen la sesión de un usuario mediante el uso de cookies, ya que HTTP es sin estados necesitan de alguna manera identificar cada petición que realiza el usuario y para ello envía las cookies, el problema es que el servidor no tiene manera de saber si la petición fue realizada desde el sitio web legítimo o de un tercero.
Mitigación
La principal solución recomendada por OWASP y una de las más utilizada por los frameworks, Django es uno de ellos, es utilizar un token específico por sesión que debe ser enviado como parámetro en todas aquellas peticiones POST, PUT, DELETE, PATCH o cualquier método que ejecute alguna acción en el servidor y en caso de no se envíe el token o no coincida la petición es rechazada.
Aclaración: la recomendación previa no tiene validez si el sitio es vulnerable a XSS ya que se puede acceder al token y luego enviarlo en la petición falsa.
Enlaces
En este artículo participaron:
No hay autores registrados