El ataque Cross-Site Request Forgery (CSRF) es una ataque que a diferencia del Cross-Site Scripting, se basa en la confianza de una web en el usuario que va a ser víctima del ataque. Aprovechando esa confianza y a través de los permisos efectivos en ese momento de ese usuario en la web, se pueden ejecutar scripts para que la víctima ejecute acciones sin ser consciente de ello.

Este tipo de ataques se centra no tanto en el robo de datos ya que el atacante no puede ver la respuesta a la petición manipulada sino en el cambio de estado de los mismos. Dependiendo del nivel de acceso de la víctima el atacante podría desde cambiar datos de la cuenta de la víctima hasta tomar control de la aplicación web pasando por transferir dinero,etc... Vamos a poner un ejemplo teórico muy sencillo para que veamos claramente el funcionamiento de este ataque.

Supongamos el usuario A está navegando y tiene abierta una sesión en la página de su banco y a la vez tiene abiertas otras tantas pestañas en el navegador. En una de estas pestañas, solo cargándola en el navegador, el usuario A podría estar ejecutando sin saberlo código destinado a un ataque CSRF contra su banco. La página web del banco en ese momento tiene la sesión abierta y autenticada con nuestro navegador por lo que no puede distinguir que peticiones envía legítimamente el usuario A por sí mismo, de otras que le lleguen a través del mismo navegador. A través de este código se pueden ejecutar acciones en la web del banco sin que el usuario sea consciente. Por eso decíamos antes que el Cross-Site Request Forgery se aprovecha de la confianza de la web en el usuario.

Para la mayoría de servicios web, las peticiones incluyen las credenciales del usuario autenticado ya sea a través de cookies de sesión, IP, credenciales de dominio,etc... por ello si la aplicación web no cuenta con las medidas para contrarestar CSRF, no tendría manera de distinguir entre las peticiones legítimas de la víctima y las que a través de un ataque CSRF se lancen en su nombre en ese mismo momento en el que está autenticado. Aunque la mayoría de scripts actualmente de CSRF son estáticos existen teóricamente también ataques dinámicos que pueden adaptarse a las sesiones que tengamos abiertas en nuestro navegador.

Es posible incluso almacenar un ataque CSRF en el propio servidor, a través de un tag de IMG o IFRAME en el código, esto se denomina "Stored CSRF Flaws". En este caso es más probable que el ataque sea  exitoso ya que la víctima estará autenticada en el momento de ejecutar ese código en esa determinada web. Este tipo de ataque se ha encontrado principalmente en foros donde cualquier usuario puede postear fácilmente imagenes y tendrá un gran número de víctimas potenciales de su script.

Otra variante de un ataque CSRF sería la de “Login CSRF” en este caso un atacante podría forzar a una víctima a loguearse con las credenciales del atacante en un servicio, en el caso que la víctima no detecte esto continuará trabajando normalmente y a posteriori el atacante podrá entrar con sus propias credenciales y ver actividad, archivos,etc.. que la víctima haya podido dejar en el servicio.

Limitaciones

Los ataques Cross-Site Request Forgery dependen de la posibilidad de ejecutarse en un entorno con unas características bastante limitadas:

  • El atacante debe atacar a una web que no compruebe el header de referrer o a una víctima que un navegador o plugin que permita referer spoofing
  • El atacante debe encontrar una manera de enviar las peticiones a la web para obtener algún tipo de resultado
  • El atacante debe acertar con todos los valores correctos de la petición ya que no podrá ver el output de la misma
  • El atacante debe hacer que la víctima ejecute el código malicioso en el momento que esté logueado en la web objetivo

Prevención

La prevención de este ataque se realiza añadiendo métodos de autenticación adicionales para las peticiones. De esta manera se pueden detectar peticiones no autorizadas. Algunas de las técnicas que implantan esto son las siguientes:

Synchronizer token pattern

Esta técnica incluye un token único y secreto para cada petición web (o sesión) ,el token se genera aleatoriamente y es comprobado por el servidor. De esta manera un atacante no puede conocer cual es el valor correcto y por tanto no puede enviar una petición efectiva al servidor.

Cookie-to-Header Token

Este sistema es usado por la mayoría de aplicaciones web basadas en JavaScript. En el momento del login la aplicación web crea una cookie con un token único y aleatorio para la sesión. El JavaScript en el cliente lee el valor y lo añade a la cabecera de cada petición HTTP. La seguridad de este método se basa en que solo el JavaScript original puede leer este token y por tanto no se podrá crear una cabecera HTTP por otro script utilizandolo.

Adicionalmente existen diversos plugins para el navegador destinados a reducir la posibilidad de este tipo de ataques, aunque en este caso los propios navegadores y sobretodo los servidores web deben hacerse cargo de evitar los CSRF.

Recursos adicionales

En los siguientes enlaces de referencia disponéis de muchos ejemplos e información sobre CSRFs y los diferentes métodos de mitigación de los mismos.

OWASP Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet
Wikipedia Cross-site request forgeryCross-site request forgery
Acunetix CSRF Attacks, XSRF or Sea-Surf – What They Are and How to Defend Against Them