Ist "curl -u Benutzername: Passwort http://example.com" sicher?

30

Ist curl -u username:password http://example.comsicher

Wenn nicht, können Sie kurz erläutern, wie jemand an Ihr Passwort gelangen kann?

security curl

— JDiMatteo
quelle

6

Wenn Sie das in einem Terminal verwenden, denken Sie daran, dass beide Anmeldeinformationen im Bash-Verlauf gespeichert sind?

— Francisco Tapia

15

Ein solcher Befehl ist nicht sicher, da ein anderer Benutzer möglicherweise verwendet, ps -efum festzustellen, welche Prozesse ausgeführt werden. Wenn Sie curl -u username:password http://example.comin der Liste erscheinen, sind Ihr Ziel, Ihr Benutzername und Ihr Passwort gefährdet.

— Lambert

Obwohl die Frage hier zum Thema gehört, könnte Sie auch Informationssicherheit

— StackExchange

54

Dies ist nicht sicher, da cURL standardmäßig die Standardauthentifizierung verwendet , bei der das HTTP-Protokoll Ihr Kennwort im Klartext sendet. Wenn Sie die username:passwordZeichenfolge angeben , wird sie in eine BASE64- Zeichenfolge im HTTP-Header konvertiert :

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

Jeder, der in der Lage ist, Ihren HTTP-Datenverkehr abzufangen (Ihr Provider, jeder, der auf denselben WLAN- Zugangspunkt zugreift wie Sie usw.), kann das Kennwort mithilfe eines Online-BASE64-Konverters wiederherstellen .

Das HTTPS-Protokoll verbessert die Situation, indem eine verschlüsselte Verbindung hergestellt wird, bevor dieser Header gesendet wird, und verhindert, dass das Kennwort preisgegeben wird. Dies gilt jedoch nur, wenn der Benutzer aufgefordert wird, unbekannte Zertifikate zu bestätigen, Sicherheitsausnahmen zuzulassen usw.

Beachten Sie, dass möglicherweise Befehlsargumente für andere Benutzer auf demselben Computer verfügbar sind, um z. B. das ps -efDateisystem / proc in Ihrem Bash-Verlauf und in Ihrem Terminal-Protokoll anzuzeigen (vielen Dank für den Kommentar von @ Lambert, der dies bemerkt). cURL versucht auf einigen Plattformen, das Kennwort auszublenden, sodass beispielsweise bei ps -efIhnen wahrscheinlich ein Leerzeichen anstelle eines Kennworts angezeigt wird. Anstatt das Passwort als Befehlszeilenargument zu übergeben, ist es jedoch besser, cURL direkt zur Eingabe eines Passworts aufzufordern, wie in der cURL-FAQ beschrieben .

— Dmitry Grigoryev
quelle

4

Selbst wenn Sie sich auf einer Plattform befinden, auf der curl erfolgreich sein eigenes Argument überschreibt, um Daten zu verbergen ps, dauert es eine Weile, bis das Überschreiben durchgeführt wird, bei dem dieser Inhalt anfällig ist.

— Charles Duffy

Was ist mit Digest-Authentifizierung? Verwendet Curl das nicht standardmäßig?

— rr

2

Die @ rr Digest-Authentifizierung ist nur unwesentlich besser, da sie Man-in-the-Middle-Angriffe nicht verhindert, sodass Sie mit HTTPS immer noch besser dran sind.

— Dmitry Grigoryev

1

@rr Wie können Sie behaupten, dass StartSSL von den meisten Browsern nicht als vertrauenswürdig eingestuft wird ? Erwarten Sie viele Benutzer von Windows 95 oder Firefox 1.5?

— Hagen von Eitzen

1

@rr IMHO werden Sie nur dann nicht vertrauenswürdig, wenn es ein Problem mit fehlenden (oder falschen) Zwischenzertifikaten auf dem Server gibt

— Hagen von Eitzen,

24

Es ist nicht sicher. Befehlszeilenparameter sind für alle Benutzer sichtbar.

— Tronic
quelle

4

Zusammen mit @Dmitry Grigoryev Antwort könnte es die genaueste sein.

— Francisco Tapia

1

Ja, ich habe den großen Teil des Problems, das ich zugeben muss, völlig verpasst.

— Dmitry Grigoryev

Befehl könnte Teil eines Skripts sein, das nur vom Benutzer gelesen werden kann ...

— Pete

2

@Pete-Befehlszeilen zum Ausführen von Programmen (unabhängig davon, ob sie über ein Skript oder ein Terminal gestartet wurden) sind normalerweise für alle Benutzer über den psBefehl und das /procDateisystem sichtbar . Wenn der Befehl schnell beendet wird, wird das Risiko verringert, aber es ist immer noch da.

— RBerteig

2

@Pete Answers sollen nicht exklusiv sein, sie ergänzen sich. Es ist also in Ordnung, wenn die zweite Antwort die in der ersten erläuterte Bedrohung weglässt. Es wäre jedoch überflüssig, sie zu wiederholen. Und ich würde die Aussage nicht falsch nennen, weil es nicht in jedem Fall möglich ist.

— Dmitry Grigoryev

1

Dies könnte mit dem Parameter --netrc-file sicherer gemacht werden.

Erstellen Sie eine Datei mit 600 Berechtigungen

Zum Beispiel: vi / root / my-file

machine example.com

Login Benutzername

Passwort PASSWORT

Speichern und schließen Sie die Datei

Verwenden Sie das unten stehende, um auf die URL mit Benutzername und Passwort zuzugreifen.

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

Getan

— Schande
quelle

0

Es ist unsicher, wenn das HTTP-Schema verwendet wird. Um es sicher zu machen, sollten Sie HTTPS verwenden.

Geben Sie nur den Benutzernamen an, um zu verhindern, dass das Kennwort im Befehlsverlauf angezeigt wird. Curl fordert zur Eingabe eines Kennworts auf, wenn dies nicht im Befehl angegeben ist.

— Mohnish
quelle

Keine nützliche Antwort, wenn HTTPS nicht verfügbar ist. cURL ist ein "Client".

— McKenzm

0

Kurze Antwort ist nein ... aber ....

Wenn es keine serverseitigen Optionen gibt, können Sie die Sicherheit verbessern.

Wenn es sich um ein lokales Intranet handelt, isolieren Sie die Broadcast-Domäne und verwenden Sie weder WLAN noch ein Radio.
Verwenden Sie, wie Shameer sagt, eine .netrc-Datei, und halten Sie die Werte aus dem Code heraus.
Wenn Sie sicher sind, dass der Speicher sicher ist, verwenden Sie Umgebungsvariablen. $ PSWD.
Wenn dies eine Automatisierung ist, führen Sie sie über die crontab von root aus.
... in einem Container.
... von einer VM mit einer verschlüsselten Festplatte.

Nichts davon ist weniger sicher als ein Browser, der HTTP verwendet.

— mckenzm
quelle