En las guías se indica que la protección CSRF se deshabilite ¿es correcto?
Sí, es correcto. La protección CSRF está centrada en sitios web que mantienen la sesión de usuario pero no es necesaria para servicios sin sesión y con mecanismo de autenticación vía token como lo es FundewebJS.
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:
- Haces login
- En la respuesta se inserta una cookie en el navegador para que mantenga la sesión (como hace el CAS)
- 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:
- Haces login
- Se devuelve un token de usuario
- 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
Si vemos este error en el pom, que nos lo marca en el <parent>:
Se debe a que en el proyecto hay algún carácter inválido, así que deberemos revisar en busca de alguna ñ, acentos o caracteres especiales, incluidos los comentarios. Puede pasar, por ejemplo, que al copiar y pegar se ponga algo que no se pueda sin que nos demos cuenta.
Error creating bean with name 'entityManagerFactory'
Este error, cuya primera línea nos dice esto:
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactory' defined in class path resource [org/springframework/boot/autoconfigure/orm/jpa/HibernateJpaConfiguration.class]: Invocation of init method failed; nested exception is javax.persistence.PersistenceException: [PersistenceUnit: default] Unable to build Hibernate SessionFactory; nested exception is org.hibernate.MappingException: Could not get constructor for org.hibernate.persister.entity.SingleTableEntityPersister
Puede deberse a un import incorrecto. En el caso que nos ha ocurrido, ha sido por importar la anotación Transient de java.beans, en vez de de javax.persistence (todo lo de persistencia debe importarse de esta librería). Como el error explica más bien poco, debemos repasar los imports a ver si esa es la causa.