ajax - tokens - csrfguard
token anti-CSRF y Javascript (1)
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, así 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é pasa si quiero usar un nuevo token 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 un script que solicitaría un token y luego lo usaría para realizar la solicitud, pero de nuevo está prohibido el uso de JavaScript entre dominios. ¿Se puede hacer con flash?
Tal vez otro enfoque para proteger las llamadas ajax de CSRF?
¡Gracias!
Existen varias técnicas que, cuando se usan juntas, proporcionan una protección CSRF suficiente.
Ficha única
Un solo token específico de sesión es lo suficientemente bueno para la mayoría de las aplicaciones. Solo asegúrese de que su sitio no tenga ninguna vulnerabilidad XSS, de lo contrario, cualquier tipo de técnica de token que emplee es un desperdicio.
La llamada AJAX para regenerar el token es una mala idea. ¿Quién cuidará a los guardias? Si la llamada AJAX en sí misma es vulnerable a CSRF, de alguna manera anula el propósito. Múltiples fichas con AJAX son, en general, una mala idea. Le obliga a serializar sus solicitudes, es decir, solo se permite una solicitud AJAX a la vez. Si está dispuesto a vivir con esa limitación, quizás pueda combinar el token para la segunda llamada AJAX en respuesta a la primera solicitud.
Personalmente, creo que es mejor volver a autenticar al usuario para 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 solicitudes y verificar su presencia en el lado del servidor. La clave / valor real no necesita ser secreto, el servidor solo necesita asegurarse de que existe en la solicitud entrante.
Este enfoque es lo suficientemente bueno como para proteger CSRF en las versiones más nuevas de los navegadores, sin embargo, es posible que esto no funcione si su usuario tiene una versión anterior para Flash Player.
Comprobando el Referente
La comprobación del encabezado de referencia también es buena para proteger CSRF en los navegadores más nuevos. No es posible falsificar este encabezado, aunque fue posible en versiones anteriores de Flash. Entonces, si bien no es infalible, todavía agrega algo de protección.
Resolviendo captcha
Forzar al usuario a resolver un captcha también es efectivo contra CSRF. Es un inconveniente como el infierno, pero bastante eficaz. Esta es quizás la única protección CSRF que funciona incluso si tiene vulnerabilidades XSS.
Resumen
- Use un token basado en sesión, pero vuelva a autenticarse para transacciones de alto valor
- Agregue un encabezado http personalizado y también verifique la referencia. Ambos no son infalibles por sí mismos, pero no hacen daño