Recuperación de tokens CSRF entre dominios usando JSONP, ¿riesgoso?

Question

Recuperación de tokens CSRF entre dominios usando JSONP, ¿riesgoso?

#1 de bobince (3 votos)
#2 de ndrix (2 votos)

4

Mirando esta pregunta anterior , la respuesta sugiere que usar un GET La solicitud para recuperar un token CSRF para hacer un POST es un método legítimo para prevenir ataques CSRF.

Tengo dos sitios web y se utiliza un formulario para comunicarse entre ellos: un formulario de inicio de sesión. Estos dos sitios están en subdominios separados, y el formulario en el Sitio A es: <form method="post" action="https://siteB.com/login">..</form>

El sitio B requiere que se envíe un token CSRF a través de una entrada oculta, por lo que en la carga de la página, hago una llamada JSONP a //siteB.com/getCSRFToken , que devuelve el token válido. Utilizo javascript para insertar el elemento de entrada oculto en el formulario, el usuario no sabe nada y el formulario se envía correctamente.

¿Existen posibles implicaciones de seguridad al hacer esto? SiteB es una aplicación Node respaldada por Express, por lo que solo estoy usando su middleware CSRF para manejar la generación / vencimiento.

csrf

pregunta Julian H. Lam 23.04.2014 - 01:40

fuente

2 respuestas

2

El motivo de los tokens CSRF es garantizar que un atacante no pueda obligarte a enviar algo sin que lo sepas. Si un atacante creara un formulario en su sitio, diga evil.com, puede completar fácilmente el token CSRF haciendo la misma solicitud JSONP.

Otro, aunque quizás sea difícil de implementar, es que el sitio A cree un token, lo envíe al sitio B, y este último verifica si el CSRF es válido usando alguna llamada JSON al sitio A. De esta manera, puede asegurarse de que se utilizó el sitio A para enviar el formulario.

Es simplemente un "¿es correcto este token?" versus un "dame un token correcto".

respondido por el ndrix 23.04.2014 - 07:03

fuente

Lea otras preguntas en las etiquetas csrf

¿Cuáles son los beneficios de tener múltiples patrones de sobrescritura para una eliminación segura? [duplicar] Contraseñas hash para autenticación NTLM

score 3 · Accepted Answer

En este caso, lo estoy usando para un conjunto de formularios de inicio de sesión / registro, por lo que no hay fugas de información

La existencia de un getCSRFToken JSONP API sin ninguna otra limitación en el sitio de la persona que llama es efectivamente una omisión completa para toda la protección CSRF.

Si crees que eso no es un problema, solo debes deshacerte del sistema de protección CSRF, ya que no hace nada por ti.

Si tiene otros formularios que aún deberían estar protegidos, querría eliminar la protección de los formularios de inicio de sesión / registro.

Si necesita protección CSRF en sus formularios de inicio de sesión, deberá establecer una sesión entre dominios. Si el sitio A y el sitio B están en el mismo servidor, no está mal, ya que puede crear un token en uno que se pueda leer desde el otro. Si están separados, entonces tienes sesiones federadas, lo que supone mucho más trabajo.

todo lo que podrían hacer es permitir al usuario iniciar sesión, ¿no?

Eso puede ser un problema basado en cómo funciona su aplicación. ¿Cuál sería el resultado si, en el medio de usar tu aplicación, un sitio hostil en otra pestaña pudiera cambiar de manera silenciosa de una cuenta a otra?

Si, por ejemplo, el usuario no nota que su cuenta ha cambiado e ingresa información confidencial para almacenarla en una cuenta que no es de ellos, sino de un atacante, eso podría ser bastante malo.