¿Es seguro "curl -u username: password http://example.com"?

30

Es curl -u username:password http://example.comseguro?

Si no, ¿puede dar una breve explicación de cómo alguien podría obtener su contraseña?

security curl

— JDiMatteo
fuente

66

si está usando eso en una terminal, ¿tiene en cuenta que ambas credenciales se almacenan en el historial de bash?

— Francisco Tapia

15

Tal comando no es seguro porque otro usuario podría usar ps -efpara ver qué procesos se están ejecutando. Cuando curl -u username:password http://example.comaparece en la lista, su destino, nombre de usuario y contraseña se ven comprometidos.

— Lambert

Aunque la pregunta es sobre el tema aquí, también puede estar interesado en StackExchange de seguridad de la información

— IQAndreas

54

No es seguro, porque cURL se predetermina a la autenticación básica donde el protocolo HTTP envía su contraseña en texto claro. Cuando especifica la username:passwordcadena, se convierte en una cadena BASE64 en el encabezado HTTP:

GET / HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

Cualquier persona que pueda interceptar su tráfico HTTP (su proveedor, cualquiera que acceda al mismo AP inalámbrico que usted, etc.) podrá recuperar la contraseña simplemente usando un convertidor BASE64 en línea .

El protocolo HTTPS mejorará las cosas al establecer una conexión cifrada antes de que se envíe este encabezado, evitando que se revele la contraseña. Sin embargo, esto solo se aplica si el usuario presta atención cuando se le solicita confirmar certificados desconocidos, autorizar excepciones de seguridad, etc.

Tenga en cuenta que los argumentos de comando pueden estar disponibles para que otros usuarios en la misma máquina los vean, por ejemplo ps -ef, / sistema de archivos proc, en su historial de bash y en su registro de terminal (gracias por el comentario de @ Lambert que lo señala). cURL en algunas plataformas intenta ocultar la contraseña, por lo que, por ejemplo ps -ef, es probable que vea un espacio en blanco en lugar de una contraseña. Sin embargo, en lugar de pasar la contraseña como un argumento de línea de comandos, es mejor que cURL solicite una contraseña directamente, como se explica en las preguntas frecuentes de cURL .

— Dmitry Grigoryev
fuente

44

Incluso si está en una plataforma donde curl sobrescribe con éxito su propio argumento para ocultar datos ps, hay un período mientras se inicia antes de que se realice esa sobrescritura donde ese contenido es vulnerable.

— Charles Duffy

¿Qué pasa con la autenticación de resumen? ¿Curl no usa eso por defecto?

— rr-

2

La autenticación de @rr Digest es marginalmente mejor, ya que no evita los ataques de hombre en el medio, por lo que aún es mejor usar HTTPS.

— Dmitry Grigoryev

1

@rr ¿Cómo afirmas que la mayoría de los navegadores no confían en StartSSL ? ¿Espera muchos usuarios de Windows 95 o Firefox 1.5?

— Hagen von Eitzen

1

@r En mi humilde opinión, no confías solo si hay un problema con la falta (o incorrecto) de certificados intermedios en el servidor

— Hagen von Eitzen

24

No es seguro Los parámetros de la línea de comando son visibles para todos los usuarios.

— Tronic
fuente

44

La fusión con la respuesta de @Dmitry Grigoryev podría ser la más precisa.

— Francisco Tapia

1

Sí, perdí por completo la gran parte del problema que debo admitir.

— Dmitry Grigoryev

el comando podría ser parte de un script que solo el usuario pueda leer ...

— Pete

2

Las líneas de comando de @Pete de los programas en ejecución (ya sea que se inicien desde un script o en una terminal) generalmente son visibles para todos los usuarios a través del pscomando y el /procsistema de archivos. Si el comando finaliza rápidamente, el riesgo se reduce, pero sigue ahí.

— RBerteig

2

Se supone que las respuestas de @Pete no son exclusivas, se complementan entre sí. Entonces, está bien que la segunda respuesta omita la amenaza explicada en la primera, más bien, sería redundante repetirla. Y no llamaría falsa a la declaración porque no es verdad en todos los casos posibles.

— Dmitry Grigoryev

1

Esto podría hacerse de una manera más segura usando el parámetro --netrc-file.

Crea un archivo con 600 permisos

Por ejemplo: vi / root / my-file

máquina ejemplo.com

iniciar sesión USERNAME

contraseña CONTRASEÑA

Guarde y cierre el archivo

Use lo siguiente para acceder a la URL con nombre de usuario y contraseña.

curl --netrc-file / root / my-file http://example.com

Hecho

— Shameer
fuente

0

Es inseguro cuando se usa el esquema HTTP. Para hacerlo seguro, debe usar HTTPS.

Para ocultar que la contraseña no aparezca en el historial de comandos, solo proporcione el nombre de usuario. Curl solicitará la contraseña, si no se proporciona en el comando.

— Mohnish
fuente

No es una respuesta útil si HTTPS no está disponible. cURL es un "cliente".

— mckenzm

0

La respuesta corta es no ... pero ...

Si no hay opciones del lado del servidor, puede reforzar la seguridad.

Si se trata de una intranet local, aísle el dominio de transmisión y no use WiFi ni ninguna radio.
Como dice Shameer, use un archivo .netrc, mantenga los valores fuera del código.
Si confía en que la memoria es segura, use variables ambientales. $ PSWD.
Si esto es automatización, ejecute desde el crontab de root.
... en un contenedor.
... desde una VM con un disco encriptado.

Ninguno de estos es menos seguro que un navegador que utiliza HTTP.

— mckenzm
fuente