¿Cuándo debo generar un nuevo token CSRF?

Question

¿Cuándo debo generar un nuevo token CSRF?

#1 de Xander (4 votos)

8

Estoy creando un método de prevención CSRF en nuestro marco de aplicación. Utilizo, entre otras cosas, el sitio OWASP .

Hemos elegido para la medida de prevención "Enviar cookies de doble", que se describe en la OWAS CSRF hoja de trucos

Los estados de la hoja de trucos:

Cuando un usuario se autentica en un sitio, el sitio debe generar un Valor pseudoaleatorio (criptográficamente fuerte) ...

Parece que un usuario debe iniciar sesión primero, antes de generar el token CSRF (también conocido como "valor pseudoaleatorio (criptográficamente fuerte)").

¿Pero cómo protejo los formularios a los que se puede acceder sin autenticación? Piense en la "contraseña olvidada" y el formulario de inicio de sesión.

Creo que el texto debería ser "Cuando un usuario entra en un sitio, el sitio debe generar un valor pseudoaleatorio (criptográficamente fuerte) ..."

Esto también es más fácil de implementar, como lo hice de la siguiente manera:

La aplicación recupera la solicitud GET: genera una cookie CSRF (sesión) (si la cookie no está ya solicitada)
(else) La aplicación recupera la solicitud no GET (POST, PUT, etc.): validar la cookie CSRF con el token CSRF en la solicitud.

¿Me estoy perdiendo un aspecto importante aquí?

csrf

pregunta Julian 15.12.2014 - 21:40

fuente

1 respuesta

Lea otras preguntas en las etiquetas csrf

redes LTE y MITM La salida SHA-3 más corta

score 4 · Accepted Answer

Normalmente, no protege los formularios que son accesibles sin autenticación. El propósito de un ataque CSRF generalmente es que un atacante manipule a un usuario autenticado para que realice una acción en el sitio con los datos del atacante y la sesión autenticada del usuario víctima. Los formularios que no requieren autenticación generalmente no son vulnerables a ser manipulados de esta manera.

Por lo tanto, las mitigaciones de CSRF se enmarcan normalmente utilizando un lenguaje que supone / requiere que el usuario esté autenticado para que exista la vulnerabilidad. Al agrupar formas no autenticadas, el modelo de amenaza cambia a uno que puede ser válido para una interacción determinada, pero no es estándar.

Tu enfoque

Forme una perspectiva de seguridad, su enfoque se ve bien. Elimina la capacidad de generar un POST o PUT sin un GET anterior, pero para una interfaz basada en navegador que generalmente no debería ser un problema, y para este modelo de amenaza específico, es exactamente lo que necesita.