token anti-CSRF y Javascript

Question

Estoy tratando de proteger una aplicación (php y un montón de JS) de CSRF.

Quiero usar tokens.

Muchas operaciones se realizan con AJAX, por lo que tengo que pasar el token en Javascript. Si quiero generar 1 token por sesión o por carga de página, es simple: genero un token nuevo, lo coloco en algún lugar en un DOM y luego lo encuentro con Javascript y lo envío al lado del procesamiento.

Pero, ¿qué sucede si quiero utilizar un token nuevo para cada operación? Estaba pensando en hacer una llamada ajax para regenerar el token y luego pasar el resultado a la página de procesamiento.

¿Aumenta esto el riesgo de seguridad? Estaba pensando en atraer al usuario a la página con el script que pediría el token y luego usarlo para hacer la solicitud, pero de nuevo, el dominio cruzado de Javascript está prohibido. ¿Se puede hacer con flash?

¿Quizás otro enfoque para proteger llamadas ajax de CSRF?

Gracias!

Answer 1

Existen varias técnicas que, cuando se utilizan juntas, proporcionan una protección CSRF suficiente.

único token

Una muestra única, específica de la sesión es lo suficientemente bueno para la mayoría de aplicaciones. Solo asegúrese de que su sitio no tenga vulnerabilidades XSS, de lo contrario cualquier tipo de técnica de token que emplee es un desperdicio.

Llamada de AJAX para regenerar el token es una mala idea. ¿Quién protegerá a los guardias? Si la llamada AJAX en sí misma es vulnerable a CSRF, de alguna manera se frustra el propósito. Múltiples tokens con AJAX son en general una mala idea. Te obliga a serializar tus solicitudes, es decir, solo se permite una solicitud AJAX a la vez. Si está dispuesto a vivir con esa limitación, tal vez pueda utilizar el token para la segunda llamada AJAX en respuesta a la primera solicitud.

Personalmente, creo que es mejor volver a autenticar al usuario para las transacciones críticas y proteger las transacciones restantes con el token específico de la sesión.

encabezado HTTP personalizado

Puede agregar un encabezado HTTP personalizado a cada una de sus peticiones, y comprobar su presencia en el lado del servidor. La clave/valor real no necesita ser secreto, el servidor solo necesita asegurarse de que exista en la solicitud entrante.

Este enfoque es lo suficientemente bueno para proteger CSRF en las versiones más nuevas de los navegadores, sin embargo, es posible solucionar este problema si su usuario tiene una versión anterior para Flash Player.

Comprobación Referente

Comprobación de la cabecera de referencia es también bueno para proteger CSRF en los navegadores más recientes. No es posible falsificar este encabezado, aunque sí fue posible en versiones anteriores de Flash. Entonces, si bien no es infalible, aún agrega cierta protección.

Resolver Captcha

obligando al usuario a resolver un CAPTCHA es también eficaz contra CSRF. Es incómodo como el infierno, pero bastante efectivo. Esta es quizás la única protección CSRF que funciona incluso si tiene vulnerabilidades XSS.

Resumen

1. utiliza un identificador de sesión basada, pero volver a autenticarse para transacciones de alto valor
2. Agregar un encabezado HTTP personalizado, y comprobar además referencia. Ambos no son infalibles por sí mismos, pero no duelen