"Curl -u username: password http://example.com" è sicuro?

30

È curl -u username:password http://example.comsicuro?

In caso contrario, puoi fornire una breve spiegazione di come qualcuno potrebbe ottenere la tua password?

security curl

— JDiMatteo
fonte

6

se lo stai usando in un terminale hai in mente che entrambe le credenziali sono memorizzate nella storia di bash?

— Francisco Tapia,

15

Tale comando non è sicuro perché un altro utente potrebbe utilizzare ps -efper vedere quali processi sono in esecuzione. Quando curl -u username:password http://example.comappare nell'elenco, la destinazione, il nome utente e la password sono compromessi.

— Lambert,

Anche se la domanda è in argomento qui, potresti anche essere interessato a Sicurezza degli scambi StackExchange

— IQAndreas

54

Non è sicuro, perché cURL passa automaticamente all'autenticazione di base in cui il protocollo HTTP invia la tua password in chiaro. Quando si specifica la username:passwordstringa, questa viene convertita in una stringa BASE64 nell'intestazione HTTP:

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

Chiunque sia in grado di intercettare il proprio traffico HTTP (il proprio provider, chiunque acceda allo stesso AP wireless ecc.) Sarà in grado di recuperare la password semplicemente utilizzando un convertitore BASE64 online .

Il protocollo HTTPS migliorerà le cose stabilendo una connessione crittografata prima di inviare questa intestazione, impedendo la rivelazione della password. Tuttavia, questo vale solo se l'utente presta attenzione quando gli viene chiesto di confermare certificati sconosciuti, autorizzare eccezioni di sicurezza e così via.

Si noti che gli argomenti dei comandi potrebbero essere disponibili per altri utenti sullo stesso computer per vedere, ad esempio ps -ef, il filesystem / proc, nella cronologia di bash e nel registro del terminale (grazie per il commento di @ Lambert che lo nota). cURL su alcune piattaforme tenta di nascondere la password, ad esempio ps -efè probabile che con te venga visualizzato uno spazio vuoto anziché una password. Tuttavia, invece di passare la password come argomento della riga di comando, è meglio che cURL richieda direttamente una password, come discusso nella faq cURL .

— Dmitry Grigoryev
fonte

4

Anche se sei su una piattaforma in cui l'arricciatura sovrascrive correttamente il proprio argv per nascondere i dati ps, c'è un periodo durante l'avvio prima che venga eseguita la sovrascrittura in cui quel contenuto è vulnerabile.

— Charles Duffy,

Che dire dell'autenticazione digest? L'arricciatura non lo utilizza per impostazione predefinita?

— r-

2

L'autenticazione Digest di @rr è solo leggermente migliore, in quanto non impedisce gli attacchi man-in-the-middle, quindi stai ancora meglio usando HTTPS.

— Dmitry Grigoryev

1

@rr Come affermi che StartSSL non è attendibile dalla maggior parte dei browser ? Ti aspetti molti utenti di Windows 95 o Firefox 1.5?

— Hagen von Eitzen,

1

@rr IMHO non ti fidi solo se c'è un problema con certificati intermedi mancanti (o errati) sul server

— Hagen von Eitzen,

24

Non è sicuro I parametri della riga di comando sono visibili a tutti gli utenti.

— Tronic
fonte

4

Unendosi alla risposta di @Dmitry Grigoryev potrebbe essere il più preciso.

— Francisco Tapia,

1

Sì, ho completamente perso la maggior parte del problema che devo ammettere.

— Dmitry Grigoryev

Il comando potrebbe far parte di uno script leggibile solo dall'utente ...

— Pete,

2

Le righe di comando di @Pete dei programmi in esecuzione (avviate da uno script o da un terminale) sono in genere visibili a tutti gli utenti tramite il pscomando e il /procfile system. Se il comando termina rapidamente, il rischio si riduce, ma è ancora lì.

— RBerteig,

2

Le risposte di @Pete non dovrebbero essere esclusive, si completano a vicenda. Quindi va bene per la seconda risposta omettere la minaccia spiegata nella prima, piuttosto sarebbe ridondante ripeterla. E non definirei falsa l'affermazione perché non è vera in ogni caso possibile.

— Dmitry Grigoryev

1

Questo potrebbe essere fatto in un modo più sicuro usando il parametro --netrc-file.

Crea un file con 600 autorizzazioni

Ad esempio: vi / root / my-file

macchina example.com

accedi USERNAME

password PASSWORD

Salva e chiudi il file

Utilizzare quanto segue per accedere all'URL con nome utente e password.

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

Fatto

— Shameer
fonte

0

Non è sicuro quando si utilizza lo schema HTTP. Per renderlo sicuro, è necessario utilizzare HTTPS.

Per nascondere la password nella cronologia dei comandi, fornire solo il nome utente. Curl richiederà la password, se non fornita nel comando.

— Mohnish
fonte

Non è una risposta utile se HTTPS non è disponibile. cURL è un "client".

— mckenzm,

0

La risposta breve è no ... ma ....

Se non ci sono opzioni lato server è possibile rafforzare la sicurezza.

Se si tratta di intranet locale, isolare il dominio di trasmissione e non utilizzare WiFi o alcuna radio.
Come dice Shameer, usa un file .netrc, mantieni i valori fuori dal codice.
Se ritieni che la memoria sia sicura, usa le variabili ambientali. $ PSWD.
Se si tratta di automazione, esegui dal crontab di root.
... in un contenitore.
... da una VM con un disco crittografato.

Nessuno di questi è meno sicuro di un browser che utilizza HTTP.

— mckenzm
fonte