Implementación de protección de patrón de token cifrado CSRF

Question

Implementación de protección de patrón de token cifrado CSRF

#1 de Michael (2 votos)
#2 de Paul Mooney (2 votos)

3

Estoy implementando la protección CSRF usando el patrón de token cifrado a>).

Entiendo que las 2 diferencias principales entre ese patrón y el Patrón de cookie de envío doble son: 1. El token en sí es un token encriptado, con vencimiento 2. el token no se almacena en una cookie, sino en un elemento DOM o variable JS (a través de un archivo JS externo minimizado y ofuscado).

También entiendo que, al igual que otros métodos de prevención, este tampoco es seguro si su sitio es vulnerable a los ataques XSS.

mis preguntas son: 1. ¿Cuál sería la caducidad recomendada para dar al token? por ejemplo, si la sesión de mi sitio dura 12 horas, ¿estaría bien establecer el vencimiento de 1 hora o se recomienda limitarlo a minutos / segundos? 2. ¿Cómo maneja el vencimiento desde la perspectiva de UX, en caso de que el vencimiento sea corto? por ejemplo, si la página se cargó a 0 s, pero la acción fue enviada por el usuario a 80 s y la caducidad es de 60 s, el token enviado caducará y la acción fallará.

Gracias, Gonen

csrf

pregunta Gonen 05.03.2015 - 13:47

fuente

2 respuestas

2

Aquí hay un desglose muy condensado sobre las diferencias entre los patrones de token cifrado y de sincronizador:

Los patrones de token cifrados no requieren estado de servidor
No requiere cookies No requiere dos tokens
No requiere ningún esfuerzo en el lado del cliente que no sea la inclusión del token en solicitudes HTTP
No requiere que ninguna otra aplicación en un subdominio sea a prueba de XSS

Esencialmente, la principal diferencia desde una perspectiva de implementación es que el Patrón de token del sincronizador requiere 2 tokens, mientras que el Patrón de token encriptado aprovecha un token único. La respuesta de Michael cubre sus preguntas en términos de tiempo de espera y actualización de UI. Para obtener más información sobre el tema, acabo de publicar esta entrada sobre cómo aprovechar el patrón de token cifrado en ASP.NET. Me complace responder a cualquier pregunta que pueda tener sobre el tema (diseñé el patrón de token cifrado).

respondido por el Paul Mooney 13.04.2015 - 09:08

fuente

Lea otras preguntas en las etiquetas csrf

¿Existe un software de codificación de disco completo que muestre un contenido diferente según la contraseña que se haya utilizado? [cerrado] ¿Es posible la seguridad de extremo a extremo sin contacto físico?

score 2 · Accepted Answer

Mi primera pregunta sería, ¿por qué no usas el ?

De todos modos, si bien las respuestas a sus preguntas no se han definido formalmente, es posible proporcionarle recomendaciones generales basadas en el patrón del token del sincronizador.

El tiempo de caducidad recomendado sería la duración de la sesión (.NET El atributo antiforgerytoken , por ejemplo, podrá validar el token anti-CSRF siempre que las cookies de la sesión sean válidas, incluso si solo las envía una vez al final de la sesión.)
No, en el caso de un token caducado, simplemente vuelve a cargar la página y le dice al usuario que algo salió mal y que tiene que enviar el formulario nuevamente. Con referencia a 1, esto solo sucederá en caso de expiración de la sesión.