Protección CSRF en mi API REST

Qué es CSRF

CSRF (Cross-Site Request Forgery) es un tipo de protección que impide que un sitio web pudiera hacer peticiones maliciosas a otro sitio web que fuese seguro, en caso de tener ambos abiertos a la vez en dos pestañas diferentes del navegador, y nos hubiésemos autenticado el segundo.

Un ejemplo sería el siguiente:

• Iniciamos sesión en mibanco.com.

• Sin cerrar sesión, abrimos otra pestaña y accedemos a sitiodudoso.com.

• Entonces, sin CSRF, sitiodudoso.com podría tener algún tipo de mecanismo, por ejemplo, un enlace que fuese muy llamativo para pinchar en el mismo, la carga de una imagen o simplemente un script de JavaScript, que pudiera hacer una petición POST.

• En esta petición, conociendo mínimamente la estructura de la API o aplicación en la cual estamos logueados en mibanco.com, se podría tratar de hacer un traspaso de dinero de una cuenta a otra.

Cómo funciona CSRF

CSRF es un mecanismo mediante el cual, para realizar este tipo de peticiones, sobre todo las peticiones POST, el cliente tiene que enviar un token, conocido como token CSRF o XSRF.

Si no se envía ese token o el que se ha enviado no es válido, la operación no sé realizaría y podríamos obtener un mensaje de respuesta como el que vemos en la imagen.

Spring Security y CSRF

Spring Security, por defecto, habilita la protección CSRF, y, además, provee de muchos mecanismos para generar dicho token, donde suelen intervenir cookies.

Por ejemplo, utilizando Thymeleaf, a la hora de implementar un formulario sin tocar nada más, si vemos el código fuente que genera el código HTML, podemos ver como el servidor se ha encargado, al procesar la plantilla y generar todo el código del formulario, de añadir ese campo de token cada vez que se vaya a enviar un campo de formulario.

Si desarrollamos una API, por ejemplo, para una aplicación de Angular, desde Spring podríamos también generar dicho token y enviarlo dentro de un encabezado.

¿Es necesario CSRF para un API REST?

Algunos autores piensan que si no va a haber cookies no haría falta la protección CSRF, por varios motivos:

• Los navegadores normalmente, y es algo que queda transparente para el usuario, se están enviando cookies constantemente. Esto se puede comprobar desde la inspección que ofrecen algunos navegadores, buscando dónde se ha hecho la petición, ver peticiones y respuestas y ver que intervienen bastantes cookies por detrás.

• Los ataques CSRF dependen mucho de este comportamiento y de la utilización de cookies, con lo cual, si no utilizamos cookies o no se confían en ellas, no habría necesidad de protegerse frente ataques de este tipo.

Por otro lado, está también el argumento de que REST es stateless (sin estado), por lo tanto:

• Una aplicación REST no se encargará de rastrear el estado del lado cliente.

• Si se utilizan sesiones a través de cookies, estaríamos tratando de rastrear este estado y, por tanto, nuestra aplicación no es totalmente REST, y, por ende, no es totalmente stateless.

• Si RESTful no debe necesitar cookies ni sesiones, por tanto, no deberíamos tener la necesidad protegernos frente a CSRF.

Conclusiones

De todo lo anterior, podemos sacar varias conclusiones

• Si de alguna manera vamos a acabar usando cookies, sí que vamos a necesitar este tipo de protección que ofrece CSRF.

Por ejemplo, si en lugar de almacenar el token JWT dentro del almacenamiento local del navegador, que quizás no sea una buena práctica, lo queremos mantener a través de alguna cookie, en ese caso tendríamos que tener cuidado y sería bueno que implementásemos la protección CSRF.

• Si lo que estamos desarrollando son aplicaciones web como tales, que tengan un motor de plantillas cómo podría ser Thymeleaf, la protección CSRF se convierte en una auténtica obligación, a la cual nos va a ayudar Spring Security.