¿Cuál es el beneficio adicional de tener un token CSRF para un enlace de activación de cuenta?

Navega tus respuestas
1

Tenemos una aplicación web sencilla donde un usuario tendrá que crear una cuenta. Para verificar su dirección de correo electrónico (que se usará para enviar notificaciones más adelante con fines comerciales, que es una de las funciones principales de la aplicación), enviamos un enlace de activación.

Nuestro enlace de activación conduce a un subdominio diferente. Debido a esto, y la capacidad del usuario para abrir este enlace de activación en una computadora / navegador diferente (como en su PC en lugar de en su teléfono), el usuario necesitará obtener un nuevo token CSRF cuando siga el enlace de activación.

Al activar su cuenta, no necesita iniciar sesión. (Puede haber iniciado sesión, pero no en la cuenta que está activando).

Entonces, al activar su cuenta, sucede lo siguiente:

  1. el usuario hace clic en el enlace,
  2. se abre el front-end que maneja dichas solicitudes,
  3. el front-end realiza una solicitud previa al vuelo a nuestro servidor para obtener un token CSRF,
  4. el front-end recibe el token CSRF,
  5. el front-end usa los parámetros pasados en la url para enviar una solicitud de activación a nuestro servidor.
  6. El servidor envía la respuesta apropiada después de manejar la solicitud
  7. La interfaz muestra la página correspondiente según la respuesta ("Se realizó correctamente, haga clic aquí para iniciar sesión" o "Su cuenta ya estaba activada, haga clic aquí para iniciar sesión" o "el enlace de activación caducó", etc.)

El punto clave aquí es que la persona que activa una cuenta no obtiene ningún derecho especial. No registramos automáticamente a la persona que activa su cuenta. Las personas todavía tienen que hacerlo ellos mismos.

Entonces, me pregunto: ¿por qué necesito este token CSRF? El enlace de activación contiene un token de activación, por lo que cualquier persona capaz de activar una cuenta tuvo suerte o recibió el correo electrónico. Si un atacante activó una cuenta, todo lo que sucedería es "la cuenta está activada".

Me gustaría quitar el token CSRF de este proceso para acelerar el proceso (especialmente para personas con Internet de alta latencia). ¿Estaría debilitando mi seguridad si eliminara el token CSRF del proceso, de modo que el proceso se resuelva a esto:

  1. el usuario hace clic en el enlace,
  2. se abre el front-end que maneja dichas solicitudes,
  3. el front-end usa los parámetros pasados en la url para enviar una solicitud de activación a nuestro servidor.
  4. El servidor envía la respuesta apropiada después de manejar la solicitud
  5. La interfaz muestra la página correspondiente según la respuesta ("Se realizó correctamente, haga clic aquí para iniciar sesión" o "Su cuenta ya estaba activada, haga clic aquí para iniciar sesión" o "el enlace de activación caducó", etc.)

TL; DR: ¿Un token CSRF agrega seguridad para los puntos finales REST donde no es necesario iniciar sesión?

    
pregunta Pimgd 03.08.2017 - 11:49
fuente

1 respuesta

1

Ok, como lo veo, hay dos solicitudes HTTP importantes aquí:

  1. El primero se genera cuando el usuario hace clic en el enlace de activación. De todos modos, este no está protegido por un token CSRF, pero contiene un token de activación. Eso suena bien.
  2. La interfaz generará un token CSRF y enviará una solicitud a su servidor para completar la activación. Si esa solicitud contiene el código de activación y el servidor lo verifica, no veo una razón para tener un token CSRF en este caso particular, aunque es difícil decirlo con certeza sin ver cómo se ven las solicitudes / respuestas y qué hacen. en el lado del servidor ¿Podría ser que el token CSRF se use más adelante para otra cosa? ¿Hay algún cambio relacionado con la seguridad en el servidor o en el lado de la clínica después de realizar estas solicitudes?

Debido a que la primera solicitud no está protegida por un token CSRF, y el token se genera sobre la marcha para la segunda solicitud, este tipo de implementación del token CSRF no tiene sentido para estas solicitudes en particular porque el atacante todavía tiene que saber solo el token de activación, si entendí todo bien.

¿Qué podría salir mal?

Un atacante no conoce el token de activación de la víctima, por lo que no puede usar ese vector de ataque en cualquier caso.

Pero un atacante podría crear su propia cuenta y hacer que la víctima la active, pero esto solo sería explotable si esa solicitud tuviera algún efecto adicional, como registrar al usuario (lo que no es el caso como describió). Solo debes tener mucho cuidado de que activar la cuenta sea el único efecto de esa solicitud.

Otro escenario descabellado sería si el servidor siempre esté generando los mismos tokens CSRF para los mismos códigos de activación. El atacante podría permitir que el servidor genere el token CSRF, pero luego interrumpir la activación de la cuenta (la segunda solicitud). Después de eso, haría que la víctima visitara el enlace con su activación, y sabría qué CSRF recibía. Pero eso también es un poco exagerado.

Además de eso, el uso de un token CSRF tiene a menudo algunos efectos secundarios agradables, como limitar XSS a XSS propio, pero eso es algo más general, no específico para su caso.

Por cierto, si quieres acelerar las cosas, ¿por qué usas la interfaz para generar la segunda solicitud? ¿Por qué no hacer que el servidor procese la primera solicitud y active la cuenta?

Y, por favor, no dé por sentado lo que dije porque es difícil dar una respuesta precisa si no veo la aplicación.

    
respondido por el pineappleman 03.08.2017 - 16:18
fuente

Lea otras preguntas en las etiquetas

Acceso a la contraseña WPA / WPA2 desde un formulario de autenticación nativo en un enrutador no autorizado ¿Cómo logró Wanna Cry superar los programas antivirus?