¿Es un problema de seguridad permitir direcciones de correo electrónico casi idénticas al registrarse?

13

Supongamos que tiene un sitio web donde es posible crear cuentas para todas las siguientes direcciones de correo electrónico:

'[email protected]'
'[email protected] '
'[email protected];'
'[email protected];[email protected]'

¿Debería considerarse esto como un problema de seguridad? He probado para ver si puede acceder a los datos de [email protected] s mientras ha iniciado sesión como [email protected]; y usted no puede .

A pesar del hecho de que no puede acceder a las cuentas creadas con direcciones de correo electrónico muy similares, esto todavía parece, por lo menos extraño y posiblemente podría dar lugar a un problema de seguridad, pero no puedo pensar en ningún problema específico. Problemas de seguridad que podrían ocurrir como resultado.

¿Puede alguien sugerir algún problema de seguridad específico al que pueda llevar esta configuración?

    
pregunta Abe Miessler 27.01.2016 - 21:00
fuente

6 respuestas

33

El primer y principal problema con este enfoque es que en su ejemplo, solo el primero es en realidad una dirección de correo electrónico sintácticamente válida. Los otros tres no lo son. Esto significa que se cumple una de las dos opciones siguientes:

  1. La "dirección de correo electrónico" es simplemente una sugerencia. El sistema quiere un identificador de inicio de sesión único; las direcciones de correo electrónico son un identificador razonablemente bueno porque los usuarios las recuerdan, y el sistema de correo electrónico ya garantiza la unicidad mundial.

  2. Realmente se supone que la dirección de correo electrónico es una dirección de correo electrónico (por ejemplo, para enviar correos electrónicos a esa dirección), y el sistema de registro falla al validar que sea lo que haya ingresado el usuario es una dirección de correo electrónico.

En el último caso, esto significa que los correos electrónicos no se transmiten, y también que el desarrollador fue muy descuidado con respecto a la validación de entrada del usuario, lo que no es una buena señal para la seguridad, en general.

Sin embargo, si los identificadores son de forma libre, entonces lo que está presenciando es el resultado de la creatividad de los usuarios humanos. No es un problema siempre que los identificadores de inicio de sesión se utilicen para lo que son. Los espacios, los puntos y coma ... pueden destruir scripts o aplicaciones mal implementados. (Intente registrarse con un nombre de cuenta que contenga una sola cita, en caso de que haya alguna posible inyección de SQL).

    
respondido por el Thomas Pornin 27.01.2016 - 21:09
fuente
17

Solo la primera dirección de correo electrónico es en realidad una dirección válida. Por supuesto, la validación de la dirección de correo electrónico es difícil , por lo que tratar de implementar la validación perfecta no tiene sentido . Como máximo, puede aproximar la validación y, por razones de facilidad de uso, debe ser indulgente con su filtro. Debido a esto, no debe basar su seguridad en la validez de las direcciones de correo electrónico.

Sin embargo, cuando requieres una dirección de correo electrónico para el registro, es habitual enviar un enlace de confirmación a esa dirección (para evitar errores tipográficos, etc.; no hacerlo puede realmente considerarse un problema de seguridad), lo que haría que tu escenario imposible.

De cualquier manera, esto no es un problema de seguridad. Su autenticación debería poder hacer frente a nombres similares, de lo contrario es errónea .

Sin embargo, tendría cuidado con los espacios al principio o al final, ya que sucede con bastante frecuencia que se recorta en algún momento, lo que en realidad puede causar problemas.

Aparte de eso, solo hay dos pequeños problemas:

  • Errores tipográficos: puede haber un usuario [email protected]:123456 y un usuario [email protected]:123456 . Si uno de ellos escribe incorrectamente sus credenciales en un accidente, puede terminar en la cuenta del otro usuario. Pero esto es una coincidencia, y no trataría de defenderme por razones de usabilidad.
  • Identificación: puede mostrar direcciones de correo electrónico en lugar de nombres de usuario, posiblemente permitiendo que un usuario imite a un usuario diferente. Por ejemplo, en su ejemplo [email protected] y [email protected] son difíciles de distinguir. Pero esto es nuevamente un caso de esquina, porque generalmente, los nombres de usuario se muestran para identificación, no para direcciones de correo electrónico.
respondido por el tim 27.01.2016 - 21:14
fuente
1

Todos, excepto el primero, deben rechazarse simplemente porque no son direcciones de correo electrónico válidas.

Cuando los copie & pegue literalmente en su cliente de correo electrónico favorito, podrían hacer lo que usted espera, pero el comportamiento más probable es que los interprete de la misma manera. Por lo tanto, si desea que las direcciones de correo electrónico identifiquen de forma única a los usuarios, debe insistir en ingresar una (exactamente una) dirección de correo electrónico sintácticamente correcta en el formulario de registro.

    
respondido por el Philipp 27.01.2016 - 22:17
fuente
1

Definitivamente hay un problema de seguridad que proviene de un proveedor que permite el registro de direcciones de correo electrónico casi idénticas. Pero no es exactamente el que están probando tus ejemplos específicos. Y sus efectos no se limitan necesariamente a los usuarios del servicio de correo electrónico, sino que pueden afectar más ampliamente a cualquier persona que reciba el correo de un usuario de ese servicio. El peligro del que estoy hablando es el que involucra la suplantación de un usuario del servicio a los destinatarios de correo.

Para ver lo que quiero decir, primero dejemos de lado los problemas de confusión (ya bien discutidos) de lo que es y no es una dirección de correo válida y si la identificación de un usuario es en realidad la misma que la dirección de correo electrónico externa del usuario. En cambio, veamos el siguiente escenario:

El atacante quiere que se le instale malware en la computadora de Jane Smith. El atacante conoce la dirección de correo electrónico de Jane Smith, sabe que Jane Smith es muy amiga de John Anderson y sabe que John Anderson mantiene una dirección de correo electrónico activa con un proveedor de correo web mail.com en [email protected]. El atacante revisa el proceso de registro de mail.com y descubre felizmente que el servicio le permitirá registrar [email protected] (sin mayúsculas) como una dirección válida. El atacante establece su nombre "de" para la cuenta como "John Anderson", y comienza a redactar un correo electrónico de pesca submarina dirigido a Jane Smith. El atacante encuentra un documento PDF en Internet que parece ser el tipo de elemento que tanto John Anderson como Jane Smith podrían encontrar mutuamente interesantes, y luego utiliza SET para insertar en ese documento un exploit de PDF y una carga maliciosa.

El atacante envía el mensaje. Al final de Jane Smith, ella recibe un correo electrónico de "John Anderson" en la dirección [email protected]. El mensaje es un reenvío en un artículo en PDF con una recomendación de una oración de John: "Acabo de terminar esto y creo que valdrá la pena leerlo. No estoy seguro de estar de acuerdo con todos los puntos del autor, pero es muy, muy interesante. " Y debido a que mail.com certifica criptográficamente que el mensaje realmente proviene de la dirección presunta, el servicio de correo electrónico de Jane Smith dejó que el mensaje pasara a su bandeja de entrada en lugar de enviarlo a la carpeta de correo no deseado (como podría suceder si el atacante simplemente falsificara el mensaje). "de la Dirección).

Pregunta retórica: ¿cuáles son las probabilidades de que Jane Smith abra ese archivo PDF adjunto?

Respuesta: tan alto como te vas a encontrar para un ataque de pesca submarina. (Al menos sin tener acceso al sistema de correo electrónico de su empleador y hacerse pasar por su jefe, o algo así).

Las posibilidades de que un usuario típico se dé cuenta de que [email protected], [email protected], o incluso [email protected] no son el mismo remitente son bastante bajas. (Si el usuario es muy consciente de la seguridad en general, obviamente las posibilidades de detección aumentan. Aunque sospecho que no es lo que algunos podrían suponer). Si la dirección real de correo electrónico de la persona real que el atacante está tratando de suplantar ya está en la libreta de direcciones del destinatario antes de que llegue el correo electrónico del atacante, el destinatario podría (podría) recibir el aviso de que el remitente de este mensaje en particular no está allí, como esperaría el destinatario . Y él o ella podría (podría) encontrar eso un poco sospechoso. Por otra parte, es más probable que él o ella solo asuman que el corresponsal estaba enviando un correo electrónico desde una dirección nueva, ligeramente diferente, por alguna razón. O que la característica de la libreta de direcciones de su servicio de correo electrónico era delicada. O ...

Obtiene el punto: esta táctica de suplantación de la dirección de correo electrónico puede ser muy poderosa (si se pasa por alto a veces) en los ataques de phishing / pesca submarina.

En cuanto a lo que los proveedores de correo electrónico pueden hacer y están dispuestos a hacer para tratar de impedir registros de direcciones muy similares, es una práctica difícil combatir de manera efectiva incluso si un proveedor de correo electrónico lo desea. Y teniendo en cuenta que cualquier proveedor de correo dado preferiría indicar a los usuarios potenciales que se registren "Lo siento, esa dirección / identificación de usuario ya está tomada". tan pocas veces como sea posible (si reciben ese mensaje lo suficiente, podrían darse por vencidos y ver si otro servicio de correo electrónico es uno de sus nombres deseados de forma gratuita) los incentivos para los servicios de correo electrónico son para permitir el registro de prácticamente cualquier dirección de correo electrónico técnicamente válida (con pocos excepciones).

    
respondido por el mostlyinformed 28.01.2016 - 03:17
fuente
0

De acuerdo con todos los demás para afirmar que la primera dirección de correo electrónico es la única válida. También me gustaría señalar que es una mala práctica permitir espacios adicionales al final de un nombre de inicio de sesión. Si comprendo esto correctamente, está intentando identificar posibles similitudes en los inicios de sesión de usuario / cliente en el sistema.

Respondiendo a tu pregunta: "¿Debería considerarse esto como un problema de seguridad?" Mi respuesta sería, no, para cualquiera de los que no contenían espacios adicionales. De lo contrario, sí ... pero principalmente por el motivo, a continuación.

Tu pregunta; "¿Alguien puede sugerir algún problema de seguridad específico al que pueda llevar esta configuración?" Desde lo alto de mi cabeza, aunque hay potencialmente algunos más de los que actualmente conozco, lo único que consideraría es por algún tipo de problema de inyección. Pero eso se reduciría a cómo se definen los espacios adicionales en su codificación. Si está bien cerrado, no debería haber ningún problema. Pero, de nuevo, todo tipo de técnicas se están aprovechando de maneras siempre cambiantes. Así que nada es realmente seguro. Por lo tanto, solo se puede esperar e intentar lograr una mejor seguridad.

    
respondido por el Max Apex 28.01.2016 - 03:30
fuente
-3

Desarrollo aplicaciones web para vivir, y puedo decir esto. Si bien puede que no sea un "gran" riesgo de seguridad, ciertamente es un desarrollo descuidado para permitir que alguien se registre con [email protected]; y / o'[email protected] '.

Simplemente porque el desarrollador no se tomó el tiempo mínimo para agregar validación de entrada. Me refiero incluso a usar HTML5 simple, si usaste un

<input type="email" />

y probé una de las dos segundas direcciones de correo electrónico que el propio navegador le mostraría un error que dice "No es una dirección de correo electrónico válida (no se ha probado en este momento, pero supongo que dado que HTML5 ha sido una práctica habitual durante algún tiempo).

Pero como desarrollador, nunca permites que alguien se registre con nada en su correo electrónico, eso no debería estar allí. Como *, & amp ;, ^, $, etc. Debería (en mi opinión) ser un correo electrónico alfanumérico válido que termine con un @ something algo / net / org, etc.

Es una muy mala práctica no validar correctamente la entrada de sus formularios. Especialmente cuando se trata de datos de clientes potenciales, o datos de clientes, datos de estudiantes y similares. Es muy fácil para los bots de spam u otras formas de bots / humanos maliciosos encontrar y detectar este fallo y aprovechar el agujero en el proceso de entrada. Por eso, puede ser un riesgo de seguridad.

Sin embargo, sólo mis dos centavos. Espero que ayude.

    
respondido por el Jason Napolitano 28.01.2016 - 02:45
fuente

Lea otras preguntas en las etiquetas