¿Cómo hago correos electrónicos de inicio de sesión seguros? (GET / POST) [duplicado]

En primer lugar, los enlaces del correo electrónico cambian de estado todo el tiempo . Si bien los GET no idempotentes son una violación del estándar de jure, el estándar de facto es que cualquier navegador o sistema de correo electrónico que no permita que los usuarios realicen solicitudes GET para cosas como la verificación de correo electrónico, el restablecimiento de contraseñas y otros servicios diversos. El uso de inicio de sesión sin contraseña basado en correo electrónico (como Slack) es un navegador o cliente de correo que todo el mundo considerará roto. Otro ejemplo común es el enlace "cerrar sesión" (que en muchos sitios es solo un GET para enlace , sin siquiera protección CSRF); Si bien esto es potencialmente un riesgo de seguridad, en la práctica se usa mucho y es difícil de explotar como algo más que una broma.

CON LO QUE DICE la forma estándar de manejar esto es de manera segura si el enlace en el correo electrónico contiene un token (único aleatorio fuerte) que lleva al usuario a una página de destino y la página de destino dice, básicamente, "hey, parece ser [nombre de usuario], haga clic AQUÍ para iniciar sesión" junto con el enlace "No [nombre de usuario]? Haga clic AQUÍ" en un texto más pequeño debajo. El enlace enviado por correo electrónico expira después de que se haga clic en cualquiera de los enlaces de la página de destino, o después de que haya transcurrido un cierto período de tiempo (generalmente no más de una hora), lo que ocurra antes. Sin embargo, la carga de la página de destino no expira inmediatamente el enlace, y los "enlaces" en la página de destino pueden ser botones de forma segura en un formulario HTML que se envía a su servicio, o JavaScript se dispara. Los "enlaces" en la página de destino idealmente deberían tener protección CSRF.

Esto tiene algunas ventajas:

• No hay problema si la página de destino se visita "antes de tiempo".
• No hay forma de que un atacante engañe a alguien para que lo firme por accidente.
• No se necesitan solicitudes GET que cambien de estado (aunque el evento JS podría simplemente desencadenar una navegación a una página impredecible de "completar este inicio de sesión", si no te importa esa parte de la especificación) .
• Permite al usuario cancelar el inicio de sesión si hizo clic en el enlace por accidente o si tiene varias cuentas y usó la incorrecta por accidente.

También tiene algunas desventajas:

• El usuario tiene que hacer clic en un tiempo adicional. Puedes mitigar esto si tienes un tiempo de espera que inicie sesión automáticamente al usuario después de unos segundos, si no hacen clic en nada o cierran la página.
• El token enviado en la URL puede permanecer activo durante un período después de ser visitado. Esto es un riesgo porque las direcciones URL a veces se registran en lugares donde los usuarios que no son de confianza pueden verlas o son de otra manera expuestas. No creo que haya ninguna mitigación para esto (aparte de que el tiempo de vida sea muy corto) aparte de hacer que el enlace sea de un solo uso, que ambos rompen "los GET deberían ser idempotentes" (no es realmente un gran problema, como se explicó anteriormente) y "la precarga de esta URL no debe romper cosas" (ver arriba).

Por cierto, los servicios de correo web y los sistemas de chat basados en la web, etc., reescriben los enlaces en los mensajes recibidos (intente copiar el enlace real de un mensaje de Gmail, por ejemplo; el texto de la barra de estado es una mentira). Cuando hace clic en el enlace, obtiene un rebote a través de una página de redireccionamiento en otra pestaña, en lugar de abrir el destino en esa otra pestaña directamente. Esto evita que cosas como la página vinculada a usar la propiedad window.opener se metan con la página webmail / chat.