Proporcionar el token CSRF al front-end, si no está presente en los encabezados de solicitud

Question

Proporcionar el token CSRF al front-end, si no está presente en los encabezados de solicitud

#1 de Shurmajee (1 votos)

1

Tengo una aplicación web en la que, cuando los usuarios solicitan una página, se genera un token CSRF y se inyecta en la página jsp en un campo oculto input .

El mismo token se envía al servidor para cada llamada AJAX en un encabezado personalizado, mientras que un token de estado de sesión está contenido en una cookie ( secure + httpOnly ).

Ahora, dado que el token CSRF es algo nuevo en la aplicación web, si después de la actualización el usuario ya inició sesión y envía una solicitud, un Filter determinará que en realidad está registrado (debido a la sesión (el token de estado en la cookie), pero un token CSRF válido no está contenido en el encabezado personalizado, por lo que el comportamiento definido es desconectarlo.

Puedo lidiar con esto, siguiendo este OWASP ejemplo. Si un token CSRF no está presente, tengo la intención de enviar una solicitud de NO-CONTENT y de alguna manera proporcionar el token.

Aquí está la primera duda:

¿No debería el el token CSRF no se debe colocar en una cookie ?

Además, están devolviendo un token CSRF si falta en la solicitud, lo que me parece un poco de anti-secure : un atacante podría haber robado el token de sesión del cookie , enviar una solicitud y recibir mágicamente el token CSRF de vuelta.

Por lo tanto, me siento confundido aquí.

¿Debo colocar el token CSRF en la cookie junto con el token de estado de sesión?
¿Debo evitar proporcionar un token CSRF si no se establece ninguno, pero existe una cookie de estado de sesión?
¿Cuál puede ser una solución alternativa para mi caso?

Notas:

Antes de verificar el token CSRF, verifico los encabezados origin y referer , como se aconseja here .

No planeo implementar un token use-only-one-per-request CSRF .

Aunque no es relevante en este contexto, la comunicación se realiza a través de HTTPS

appsec java cookies csrf

pregunta Marko Pacak 24.01.2018 - 11:42

fuente

1 respuesta

Lea otras preguntas en las etiquetas appsec java cookies csrf

¿Cómo los navegadores modernos aíslan diferentes complementos? Identificar la red del paquete inalámbrico

score 1 · Accepted Answer

Hay varias formas de abordar una vulnerabilidad CSRF. La implementación que está viendo utiliza un método sin estado para administrar el token CSRF . Esto se llama el método de doble cookie enviado. Esto le ahorra algo de esfuerzo si no desea realizar un seguimiento del token CSRF en el lado del servidor.

Desde el OWASP enlace que compartiste en la pregunta:

Una cookie de doble envío se define como enviar un valor aleatorio tanto en una cookie como en un parámetro de solicitud, con el servidor verificando si el valor de la cookie y el valor de la solicitud coinciden.

El riesgo de seguridad surge cuando su token CSRF reside solo en la cookie y en ninguna otra parte. Esto no sería suficiente para la prevención de CSRF, ya que sería lo mismo que tener otra cookie de sesión.

En la implementación de la cookie doble enviada, solo tiene que asegurarse de que los valores de token recibidos de la cookie y del parámetro de formulario sean los mismos. En el caso de un ataque CSRF, la solicitud falsificada contendría el token en la cookie, pero el valor del token desde el parámetro / encabezado personalizado estará ausente. Por lo tanto, conduce a la detección y prevención de CSRF.

Para responder a su otra pregunta sobre la devolución de un token CSRF si la solicitud está autenticada pero no contiene un token. Esto depende completamente del tipo de experiencia de usuario que desea que tengan sus usuarios. En algunos casos, puede estar bien redirigir al usuario a una página de inicio de sesión.

Digamos que devuelve el token en la cookie y hay un intento CSRF. En tal caso, Same Origin Policy evitaría que cualquier dominio malicioso acceda a el valor de la cookie directamente y, por lo tanto, la solicitud falsificada subsiguiente fallaría por las mismas razones indicadas anteriormente.

Para consideraciones de seguridad adicionales en caso de una implementación de cookie doble enviada:

Vulnerabilidades de las cookies de envío doble