sitio web que acepta autenticación a través de GET

Pregunta 1: esto no se considera seguro por varios motivos:

1. La contraseña se puede ver en la URL

2. La contraseña se puede ver en el historial del navegador

3. Todas las contraseñas estarán en los registros del servidor

4. Si el usuario inicia sesión en el sitio y hay un enlace que apunta a un sitio externo, y el usuario hace clic en él, la contraseña se filtró

5. El spyware con monitoreo de URL podrá obtener la contraseña

Creo que el problema # 3 es el más preocupante. Si alguien obtiene acceso al servidor web, tendrá todas las contraseñas para cada usuario registrado, en texto plano. Yo despediría a la persona que diseña este esquema de inicio de sesión.

Incluso si el sitio emplea SSL, esos ataques se pueden realizar y obtener las contraseñas.

Pregunta 2: Esto no es un ataque, es un error de diseño. Se abre paso a algunos ataques. Busque CSRF (o XSRF) para encontrar la forma más fácil de atacar este error de diseño.

EDIT : lo anterior es cierto SI el formulario de autenticación envía datos a través de GET, y no es el caso.

Si el atacante puede crear un formulario para convencer al usuario de que proporcione su nombre de usuario y contraseña, no importa qué tan seguro esté el servidor. No importa si el formulario utiliza GET o POST, HTTPS o HTTP, Javascript o Flash o un applet de Java o una máquina virtual que ejecute Linux sobre asm.js.

Está preguntando "¿qué tiene de malo aceptar (pero no habilitar) la autenticación basada en datos?"

La respuesta: es una mala práctica que puede llevar a una vulnerabilidad, pero no crea una vulnerabilidad directamente.

Para que exista una vulnerabilidad, debe ser explotable de alguna manera, y debe otorgarle al atacante algo que aún no tiene. En este caso, ¿cómo va a explotar el atacante la autenticación basada en obtención?

• un usuario normal usará la ui de autenticación regular basada en correos. El / ella no se verá afectado por los problemas con authn basados en get.
• un atacante que pueda configurar su propio uhn auti basado en get y que pueda convencer a sus usuarios para que se autentiquen en su authn ui no lo necesita, no lo necesita para comunicarse con su servidor; puede hacer que los usuarios envíen sus contraseñas directamente a su servidor
• un atacante que puede cambiar el comportamiento de su ui normal reescribiendo el código fuente ya tiene acceso al código fuente y puede hacerlo mucho peor.
• un atacante que puede cambiar su interfaz de usuario en tiempo de ejecución, a través de un ataque como xss ya encontró una vulnerabilidad xss separada y puede hacerlo mucho peor
• si la aplicación también tiene un problema de CSRF en la pantalla de la interfaz de usuario, el atacante puede iniciar sesión como ellos mismos en lugar del usuario normal. Sin embargo, eso es CSRF, y el uso de obtener o publicar no tiene absolutamente ninguna orientación. CSRF se puede realizar contra get y post, y deshabilitar get no deshabilitaría CSRF. Los dos temas no tienen nada que ver entre sí, excepto que ambos podrían existir en la pantalla de inicio de sesión.
• un atacante que pueda convencer a su formulario de inicio de sesión para que cambie de publicación a otro usuario puede aprovechar esta vulnerabilidad. ¿La aplicación codifica el método como post? Si no es así, ¿utiliza alguna entrada del usuario para decidir si publicar o recibir? Un atacante podría enviar por correo electrónico a la víctima una url para iniciar sesión en su interfaz de usuario, y esa url podría contener los parámetros necesarios para que cinvert desde la publicación hasta la obtención, si existen

Por lo que puedo decir, no hay otro atacante relevante para el comportamiento en cuestión. Excepto por las preguntas en la última viñeta, el atacante que puede hacer uso de este defecto ya es más poderoso de lo que el defecto otorgaría. El atacante que no tiene ese poder no puede hacer uso de esta falla.

Todo lo dicho, es una mala práctica y debería corregirse. Corregirlo (y agregar un comentario en el código que explica por qué) ayudará a evitar que los futuros desarrolladores de la aplicación hagan uso del inicio de sesión basado en Get e introduzcan una vulnerabilidad real.

Si el formulario de inicio de sesión es vulnerable a CSRF (sin importar POST o GET), este tipo de falsificación es inseguro y conocido: "login CSRF" enlace

pregunta relacionada: ¿Cómo protegerse contra el inicio de sesión CSRF?