TL; DR: maneja CSRF en el mismo lugar (puerta de enlace o un servicio detrás de él) donde manejas la autenticación. O no utilice cookies para tokens de autenticación.
La versión larga
En un diseño sin estado, el enfoque más común para la protección CSRF es doble envío de cookie . Aunque el servidor no tiene un estado o una sesión, una sesión de seguridad está presente en el lado del cliente. Es muy importante implementar la cookie de envío doble de manera que esté vinculada a esta sesión de seguridad y no hacerlo ingenuamente . Consulte este documento para más detalles.
Un método para archivar esto es incluir el token CSRF dentro de la cookie de autenticación y hacer la cookie de autenticación httpOnly. De esta manera, un atacante en un subdominio comprometido se verá obligado a sobrescribir tanto la cookie de autenticación como el token CSRF, lo que no puede hacer ya que no puede falsificar las cookies de autenticación. Incluso si tiene una cookie de autenticación válida (la suya, por ejemplo), esto cambiará de usuario autenticado y, por lo tanto, anulará el propósito de CSRF en primer lugar. Además, sobrescribir la cookie no es suficiente para derrotar a CSRF ya que la aplicación cliente no está leyendo el token CSRF de la cookie (es httpOnly) pero se le da un token CSRF en una autenticación exitosa.
Los pasos necesarios para implementar este enfoque se pueden encontrar aquí . A pesar de que la respuesta en ese enlace es sobre JWT, el mismo enfoque es válido para cualquier formato de token que use para la autenticación.
En la arquitectura de microservicio sin estado, el mejor enfoque es manejar CSRF en el mismo lugar donde maneja la autenticación, ya sea en la puerta de enlace o en algún otro servicio detrás, ya que tendrá que manejar la autenticación en cada solicitud y el token CSRF es (si implementar mi consejo arriba) atado a la autentificación. Cualquier otra opción complicará las cosas aún más y posiblemente romperá la protección CSRF por completo. Por ejemplo:
- Está procesando la autenticación en una puerta de enlace u otro servicio, pero no puede cambiar la forma en que se realiza la autenticación y, por lo tanto, no puede agregar la protección CSRF en ese lugar. En este caso, deberá extraer el token CSRF del token de autenticación y reenviarlo al servicio de destino junto con el encabezado CSRF para su procesamiento. Esto implica que tendrá que hacer protección CSRF en todos y cada uno de los servicios, lo que no es bueno. No se puede garantizar que cada servicio realizará esta comprobación. Además, deberá preocuparse por la comunicación entre servicios. Deshabilitar la protección CSRF con la presencia de un cierto encabezado es posible, pero podría ser un riesgo de seguridad en sí mismo.
- No está realizando la autenticación en una puerta de enlace o no tiene una puerta de enlace, las credenciales del cliente (token / cookie de autenticación) se reenvían a cada servicio en la cadena de solicitudes y cada servicio debe manejar su propia autenticación / protección CSRF. Igual que el anterior, no puede garantizar que cada servicio lo hará, pero el enfoque para el manejo de CSRF se describe anteriormente.
Otro enfoque para manejar CSRF es no tener cookies para tokens de autenticación y, en su lugar, utilizar encabezados para pasar tokens de autenticación. Sin embargo, en caso de una vulnerabilidad XSS, esto facilitará el robo del token de autenticación. Puede encontrar un artículo sobre este dilema aquí .