¿Cómo asegurar el punto final de validación de correo electrónico?

1

Tenemos validación de correo electrónico en nuestro formulario de registro (una llamada de Ajax a un punto final REST para validar una dirección de correo electrónico cuando un usuario ingresa). Digamos una forma normal nombre, apellido, correo electrónico, contraseña, dirección ... Tenemos 2 acciones en esta forma.

  1. Cuando el usuario ingresa un correo electrónico, hacemos una llamada al backend y verificamos si alguien ya ha recibido este correo electrónico.
  2. enviar formulario.

Tenemos un token CSRF (por solicitud en un campo oculto) para todo el formulario (por lo que recibimos un token nuevo después de la llamada de validación de correo electrónico).

Pero alguien puede crear un script para llamar al punto final de validación de correo electrónico con el token y recopilar las direcciones de correo electrónico que tenemos en el sistema.

¿Existen buenas prácticas para asegurar este tipo de escenario? También planeamos implementar la regulación.

    
pregunta Ntwobike 06.11.2017 - 19:35
fuente

2 respuestas

3

Editar para responder una pregunta real

Perdón por malinterpretar tu pregunta. Dicho esto, aquí hay una respuesta. Si su objetivo es lograr que nadie sepa qué direcciones de correo electrónico ha registrado en el sistema (lo que es un buen objetivo), la respuesta simple es que usted no puede verificar de antemano si Se toma la dirección de correo electrónico, y luego hágales saber si es así. Independientemente de las medidas de seguridad que adopte, seguirá teniendo un lugar donde la gente puede preguntar "¿está esta persona en su sitio?". Incluso la limitación de la velocidad realmente no lo hace, ya que un atacante malicioso podría estar apuntando a un usuario específico. Si ya conocen de antemano la dirección de correo electrónico de la persona, solo tienen que ir a su formulario de registro y ver si el correo electrónico ha sido recibido. En su lugar, tendrá que ajustar su paso de registro:

  1. Siempre puedes validar que se trata de una dirección de correo electrónico real (indicándoles que la dirección de correo electrónico no es una dirección de correo electrónico que protegerá contra errores tipográficos y, obviamente, no revelará nada sensible).
  2. Haga que escriban la dirección de correo electrónico dos veces: esto ayudará a evitar errores tipográficos, lo que será una gran ayuda en el próximo paso:
  3. Forzar al usuario a través de un proceso de validación de correo electrónico, como lo describo a continuación: enviarles un correo electrónico con una clave que deben usar para activar su cuenta. Esto proporciona un par de capas de protección. Si alguien está utilizando su formulario de registro para rastrear las direcciones de correo electrónico usadas, no se enterará de nada. En todos los casos, su formulario de registro devuelve un mensaje genérico "Consulte su correo electrónico para obtener instrucciones sobre cómo activar su cuenta". Si la dirección de correo electrónico ya existe, entonces, en lugar de enviar instrucciones de activación, puede enviar un "Usted acaba de intentar registrarse pero ya existe en nuestro sistema. Haga clic aquí para recuperar su contraseña. Si no intentó registrarse, haga clic aquí vincula y luego ignora este mensaje "(o algo así). De lo contrario, haga el mensaje de validación de correo electrónico normal.

Ya que no quiere decirle a la gente si intenta registrarse con un correo electrónico que ya existe, recibirá tres personas diferentes que envían su formulario de registro:

  1. Personas nuevas que intentan registrarse (estas personas no tendrán ningún problema)
  2. Personas mayores que ya están registradas pero se olvidaron: su correo electrónico alternativo les ayudará a ingresar muy rápidamente.
  3. Personas que intentan eliminar tu lista de correo electrónico. No obtendrán nada en absoluto.

Como resultado, los actores malintencionados se excluirán y sus usuarios legítimos se comunicarán sin problemas. Una buena combinación entre usabilidad y seguridad (IMO).

respuesta anterior: ligeramente aplicable

La validación correcta del correo electrónico no debería permitir que alguien pueda verificar la existencia de direcciones de correo electrónico en su sistema. Es posible que deba incluir más detalles sobre lo que está haciendo exactamente. Dicho esto, siempre vale la pena explicar cuál debería ser la respuesta :

La validación del correo electrónico se debe realizar mediante una clave criptográfica segura y aleatoria que se envíe por correo electrónico al usuario. En ese momento, la validación puede ser tan simple como hacer clic en un enlace que le envía al usuario que tiene el siguiente aspecto:

https://example.com/verify_registration?key=LONGANDRANDOMSTRING

Cosas a tener en cuenta:

  1. Asegúrese de que la clave de validación se genere con un CSPRNG adecuado: si el usuario puede adivinar la clave a partir de su entrada, es inútil.
  2. La dirección de correo electrónico del usuario no es parte de la entrada y no es necesaria en ningún paso del proceso de validación. El hecho de que el usuario conozca la clave aleatoria, que solo se entrega por correo electrónico, es lo que verifica que el usuario posee la dirección de correo electrónico. Como resultado, no debería haber ninguna oportunidad para que las personas eliminen una lista de direcciones de correo electrónico.
  3. Asegúrese de que su clave tenga suficientes bytes aleatorios que no pueda ser adivinado
  4. Normalmente, solo usaría las solicitudes de POST para realizar cambios y, por lo tanto, desea asegurarse de que este punto final tenga protección CSRF. Sin embargo, eso no es necesario aquí. La razón es que la clave en sí misma es lo suficientemente aleatoria como para que nadie, excepto la persona con el correo electrónico, la tenga de todos modos. Así que es mejor hacer que el proceso de validación se realice a través de un enlace simple y una solicitud GET . Incluso si el usuario solo tiene que copiar y pegar la clave de su correo electrónico a un formulario web, alguien se equivocará. La forma en que funciona es lo suficientemente simple y lo suficientemente segura como para que (IMO) una IU más simple sea perfectamente razonable.
  5. Vale la pena mencionarlo porque lo veo todo el tiempo: los hashes no agregan aleatoriedad a una cadena. Utilice un CSPRNG real para hacer la cadena aleatoria. No se limite a tomar algunos datos simples y hash. Los hash no agregan entropía: deben hacer que se vea al azar.
respondido por el Conor Mancone 06.11.2017 - 20:41
fuente
1

No está claro qué amenaza está tratando de manejar.

Hay algunas opciones, que resumiré desde la parte superior de mi cabeza:

  • fuga de información para un solo correo electrónico

    Tendrá que denegar el registro en algún momento, por lo que no tiene forma de hacer algo en su contra, excepto enviar la información por correo electrónico, es decir, dejar que el primer paso sea un campo de entrada que genere un correo electrónico con un enlace para continuar.

    Esto hace que el registro sea aún más tedioso, ya que de todos modos es un enfoque horrible, en cuanto a UX.

  • fuga de información con fuerza bruta

    Iterar a través de direcciones de correo electrónico (bastante largas) es tedioso, pero la limitación de la velocidad solo mantendría a los atacantes bajo control que no usan la nube para representar las solicitudes de varias direcciones IP.

    Sin embargo, puede hacer que la verificación sea costosa computacionalmente haciendo que la parte solicitante utilice las funciones hash lentas varias veces antes de enviarla a su API (parece que, de todos modos, JavaScript es necesario).

    Esto requeriría que realices esos cálculos también para cada usuario en cada registro, pero probablemente eso sea aceptable.

    Además, esto sería un desperdicio de potencia informática si no hay una lista de direcciones de correo electrónico válidas y es una iteración completamente aleatoria de las direcciones de correo electrónico válidas para RFC.

  • amenazas avanzadas donde el correo electrónico está comprometido o puede ser interceptado

    No puedes hacer nada al respecto. Esto se aplica también al primer szenario si no tiene una clave S / MIME o PGP válida para la dirección al enviar el enlace.

En términos generales, es posible que desee considerar, por ejemplo, el uso de proveedores de OAuth para la autenticación, sin tener que preocuparse por todo esto, o no usar las direcciones de correo electrónico como ID:

Si permite a los usuarios elegir un seudónimo en el registro que tiene que ser único, solo puede permitir un segundo registro para una dirección de correo electrónico; y por qué no *?

Con el correo electrónico opt-in, puede eliminar el registro pendiente si no se completa dentro de x horas. Y dado que ha recopilado una clave del usuario, también puede decirle que ya tiene una cuenta (y el seudónimo) en ese correo electrónico.

(*) Incluso los usuarios que no tienen acceso a varias direcciones de correo electrónico pueden usar la función de alias de la RFC y crear varias cuentas a menos que pruebe la igualdad, como por ejemplo, [email protected] == [email protected] . Así que los usuarios pueden crear múltiples cuentas de todos modos.

    
respondido por el Tobi Nary 07.11.2017 - 06:20
fuente

Lea otras preguntas en las etiquetas