El Cross-Side Request Forgery ( CSRF ) es una vulnerabilidad de seguridad en la que un atacante engaña a un usuario legítimo para que realice una acción no deseada en un sitio web sin su conocimiento o consentimiento.

En un ataque CSRF, el atacante engaña a la vícitima para que haga click en un enlace malicioso o visite un página web maliciosa. Esta página maliciosa puede contener una solicitud HTTP que realiza una acción no deseada en el sitio web de la vícitma.

Por ejemplo, imagina que un usuario ha iniciado sesión en su cuenta bancaria en línea y luego visita una página web maliciosa. La página maliciosa contiene un formulario que envía una solicitud HTTP al sitio web del banco para transferir fondos de la cuenta bancaria del usuario a la cuenta del atacante. Si el usuario hace click en el botón de envío sin saber que está realizando una transferencia, el ataque CSRF habrá sido exitoso.

Este ataque puede ser utilizado para realizar una amplia variedad de acciones no deseadas, incluyendo la transferencia de fondos, la modificación de información de la cuenta, la eliminación de datos y mucho más.

Para explotar un CSRF se necesita identificar el mismo, para hacerlo, podemos jugar con Burpsuite.... Supongamos que tenemos la página http://dobliuw.com en donde hay una sección de cambiar contraseña:

Si nosotros ingresamos la nueva contraseña e interceptamos con Burpsuite la petición, vemos que es una petición HTTP de tipo POST tal que asi:

Como sabemos, el CSRF consiste en una petción que realiza el usuario siendo engañado, por lo que podriamos probar si esta sección de la página
http://dobliuw.com/action/usersettings/changepassword es vulnerable a un posible CSRF, para ello simplemente tenemos que realizar un click derecho > change method request y cambiar esta petción de tipo POST a GET, en caso de que al enviar la petción habiendo sido cambiada a GET la misma funcione, es decir, que en este ejemplo cambie la contraseña, podriamos pensar en un CSRF.

Una vez que vemos que una petición que podria ser por POST es cambiada a GET y funciona, podriamos ingeniarnosla para que a la victima clickee en el enlace o carge el recurso para asi que el o ella tramite esta petición, dando como resultado que se cambie (En este ejemplo) su contraseña.

Es importante tener en cuenta que en un escenario real fuera de este ejemplo, las peticiones conlleven tokens, identificadores de usuarios, lo que conllevaria a ver si existe una manera de descubrir el id de la victima, o si los tokens son realmente necesarios, incluso si mediante otros ataques como XSS - ( Cross-Site Scripting ) se pueden obtener, etc.