formulario de inicio de sesión HTML sin una protección CSRF

32

Recientemente hemos recibido un informe de vulnerabilidad que indica que uno de nuestros formularios HTML en una de las aplicaciones internas no está protegido por CSRF. Al principio, no pudimos reproducirlo de forma manual de forma inmediata utilizando las herramientas de desarrollo que buscaban en los encabezados y las cookies, encontrando el XSRF-TOKEN presente en los encabezados.

Pero luego, reproducimos el problema en la pestaña de incógnito o en un navegador "limpio". El problema fue en el primer intento de inicio de sesión solamente. Parece que en el momento en que se publica la primera solicitud de inicio de sesión, el cliente todavía no tiene el token XSRF , ya que esta es la primera interacción entre el cliente y el servidor.

¿Sigue siendo una vulnerabilidad y debería solucionarse si solo se reproduce en la primera solicitud de inicio de sesión? ¿Cómo se aborda este tipo de problema en general? Probablemente deba haber algún tipo de interacción cliente-servidor antes del envío del formulario de inicio de sesión para que el cliente obtenga el token XSRF de antemano.

    
pregunta alecxe 13.12.2017 - 18:50
fuente

2 respuestas

39

Esto se llama "CSRF de inicio de sesión" y, de hecho, es un problema real que debe abordar.

Si bien un atacante no puede engañar a una víctima para que inicie sesión en su propia cuenta ya que el atacante no conoce las credenciales del usuario, un atacante podría engañar a la víctima para que inicie sesión en la cuenta del atacante. Esto se puede usar para engañar a una víctima y entregarle información al atacante, ya que la víctima cree que ha iniciado sesión como ellos mismos.

De hecho, esto es algo que se ha utilizado para fines maliciosos. De Detectify :

  

PayPal alguna vez fue vulnerable al inicio de sesión CSRF y el atacante podría hacer que un usuario inicie sesión en la cuenta de PayPal del atacante. Más tarde, cuando el usuario pagó por algo en línea, sin saberlo, agregaron su tarjeta de crédito a la cuenta del atacante.

     

Otro ejemplo, menos obvio, es un CSRF de inicio de sesión que una vez existió en Google, que hizo posible que el atacante permitiera al usuario iniciar sesión en la cuenta del atacante y luego recuperar todas las búsquedas que el usuario había realizado mientras estaba conectado.

Incluso si no puede pensar en alguna forma en que esto pueda aprovecharse en su sitio, un atacante inteligente podría hacerlo. No hay razón para permitirlo.

Entonces, ¿cómo lo bloqueas? Incluso si la primera acción que realiza el usuario es iniciar sesión, la primera interacción que tienen con el servidor es recuperar la página de inicio de sesión. Esa es una oportunidad para asignar un token CSRF. Luego, compruebe si hay solicitudes que cambien el estado del servidor, incluido el inicio de sesión.

(Una vulnerabilidad relacionada tangencialmente es la reparación de la sesión. Tener tokens CSRF que persisten en el inicio de sesión anterior puede exponerlo a eso, así que lea esto antes de comenzar a implementar una solución).

    
respondido por el Anders 13.12.2017 - 19:19
fuente
7

Como se explica en Anders , la falta de csrf en el formulario de inicio de sesión es una vulnerabilidad grave. Probablemente hay numerosos vectores de ataque, pero aquí hay otra posibilidad que me viene a la mente. En el peor de los casos, podría llevar al robo de las credenciales de la víctima.

Si el atacante tiene un self-xss persistente en su cuenta, conseguir que el usuario inicie sesión en su cuenta podría ser suficiente para activarlo, lo que le permite cambiar la página de origen completa y mostrar un registro o un inicio de sesión. forma.

Aquí hay un hazaña en AirBnb explotando el self-xss más la falta de token csrf en el formulario de inicio de sesión.

    
respondido por el Xavier59 13.12.2017 - 22:27
fuente

Lea otras preguntas en las etiquetas