Versiones comparadas

Clave

  • Se ha añadido esta línea.
  • Se ha eliminado esta línea.
  • El formato se ha cambiado.

...

El mecanismo del ataque es el siguiente:

Los ataques CSRF se basan sobre todo en las cookies que tienes en el navegador para intentar un ataque a través de otro sitio que "captura" y utiliza dichas cookies sin ser el destinatario legítimo, es importante saber que tras loguearnos en un sitio se nos establece una cookie en el navegador que le indica al servidor que ya somos un usuario autenticado por lo que ya no se nos vuelve a pedir login y podemos actuar sobre la aplicación con nuestro perfil. La protección CSRF se basa en añadir a las peticiones un token sólo conocido por el servidor y el destinatario real de las peticiones, de este modo aunque se capture la cookie no se podrá suplantar al destinatario ya que no se poseerá dicho token, el servidor aparte de la cookie validará el token en cada petición, si es incorrecto o no viene denegará dicho acceso.


En el caso de una aplicación sin sesión y en FundewebJS, tras el login se genera un token ( JWT ) que es el que valida el servidor, este token firmado no se puede modificar y sólo estará accesible para el destinatario real de la petición (importante mantener comunicaciones https), no tiene sentido activar la protección CSRF porque ya estamos introduciendo un mecanismo de validación vía token.


Sistema CON sesión:

  1. Haces login
  2. En la respuesta se inserta una cookie en el navegador para que mantenga la sesión (como hace el CAS)
  3. Si entras en otra pestaña a "www.sitiochungo.com" y sabe cómo es tu API podrá intentar coger la cookie y actuar en nombre del usuario logueado.

¿Cómo lo soluciona la protección?: Añade un token CSRF que tiene que enviar en todas las peticiones el cliente de manera que aparte de la cookie necesitas ese token el cual sólo lo puedes obtener si eres el receptor directo de la respuesta.

Sistema SIN sesión:

  1. Haces login
  2. Se devuelve un token de usuario
  3. Se envía y valida el token en cada petición

Un posible atacante tendría que ser el receptor de la petición para conocer el token que se está intercambiando.

Error en el pom.xml - Caracteres inválidos en el proyecto

...