security - Nombre de usuario y contraseña en https url

url-parameters

Question

Considere la URL: https: // foo: [email protected]

¿La porción de nombre de usuario / contraseña en el ejemplo anterior califica como un "parámetro de URL", como se define en esta pregunta ?

Answer 1

Cuando coloca el nombre de usuario y la contraseña frente al host, esta información no se envía de esa manera al servidor. En su lugar, se transforma en un encabezado de solicitud en función del esquema de autenticación utilizado. La mayoría de las veces esto será Basic Auth, que describo a continuación. Un esquema de autenticación similar (pero significativamente menos utilizado) es Digest Auth, que en la actualidad ofrece funciones de seguridad comparables.

Con Basic Auth, la solicitud HTTP de la pregunta se verá más o menos así:

GET / HTTP/1.1
Host: example.com
Authorization: Basic Zm9vOnBhc3N3b3Jk

La cadena tipo hash que ves allí la crea el navegador de esta manera: base64_encode(username + ":" + password) .

Para los que no pertenecen a la transferencia HTTPS, esta información está oculta (como todo lo demás en el nivel HTTP). Sin embargo, debe encargarse de iniciar sesión en el cliente y en todos los servidores intermedios. El nombre de usuario normalmente se mostrará en los registros del servidor, pero la contraseña no. Esto no está garantizado sin embargo. Cuando llamas a esa URL en el cliente con, por ejemplo, curl , el nombre de usuario y la contraseña serán claramente visibles en la lista de procesos y pueden aparecer en el archivo bash history.

Cuando utiliza el enfoque de ayush , el nombre de usuario y la contraseña aparecerán siempre en los registros del servidor web, el servidor de aplicaciones, las memorias caché, ... a menos que configure específicamente sus servidores para que no lo logren. Esto solo se aplica a los servidores que pueden leer los datos http no encriptados, como su servidor de aplicaciones.

La autenticación básica está estandarizada e implementada por los navegadores al mostrar este pequeño nombre de usuario / contraseña emergente. Cuando coloca el nombre de usuario / contraseña en un formulario HTML enviado a través de GET o POST, tiene que implementar toda la lógica de inicio de sesión / cierre de sesión (lo que podría ser una ventaja). Pero nunca debe transferir nombres de usuario y contraseñas mediante parámetros GET. Si es necesario, use POST en su lugar. Impide el registro de estos datos por defecto.

Al implementar un mecanismo de autenticación con un formulario de entrada de usuario / contraseña y una sesión posterior basada en cookies, como se usa comúnmente en la actualidad, debe asegurarse de que la contraseña sea transportada con solicitudes POST o solo uno de los esquemas de autenticación estandarizados anteriores.

Para concluir, podría decir que la transferencia de datos de esa manera a través de HTTPS es segura, siempre y cuando tenga cuidado de que la contraseña no aparezca en lugares inesperados. Pero ese consejo se aplica a cada transferencia de cualquier contraseña de cualquier manera.