“Curl -u username: şifre http://example.com” güvenli midir?


30

curl -u username:password http://example.comgüvenli?

Değilse, birisinin şifrenizi nasıl alabileceği hakkında kısa bir açıklama yapabilir misiniz?


6
Bir terminalde kullanıyorsanız, her iki kimlik bilgilerinin de bash tarihinde saklandığını aklınızda bulunduruyor musunuz?
Francisco Tapia

15
Böyle bir komut güvenli değil çünkü başka bir kullanıcı ps -efhangi işlemlerin çalıştığını görmek için kullanabilir . When curl -u username:password http://example.comlistede görünür, hedef, kullanıcı adı ve şifre ile ilgili sorunlardır.
Lambert

Buradaki soru burada olmasına rağmen, Bilgi Güvenliği
StackExchange

Yanıtlar:


54

Bu güvenli değildir, çünkü cURL varsayılan olarak HTTP protokolünün şifrenizi açık metin olarak gönderdiği temel kimlik doğrulamasını yapar . Belirttiğiniz zaman username:passworddize, bir dönüştürülür alır BASE64 HTTP başlık içinde dize:

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

HTTP trafiğinize müdahale edebilecek (sağlayıcınız, sizinle aynı kablosuz AP'ye erişen herkes vb.), Yalnızca çevrimiçi bir BASE64 dönüştürücüsü kullanarak şifreyi kurtarabilir .

HTTPS protokolü, bu başlık gönderilmeden önce şifreli bir bağlantı kurarak şifrelerin ortaya çıkmasını önleyerek işleri daha iyi hale getirecektir. Ancak, bu yalnızca kullanıcı bilinmeyen sertifikaları onaylaması, güvenlik istisnalarını yetkilendirmesi vb.

Komut argümanlarının aynı makinedeki diğer kullanıcılar için, örneğin ps -ef/ proc dosya sistemini, bash geçmişinizde ve terminal günlüğünüzde görülebileceğine dikkat edin (@ Lambert'in bu yorumu yaptığı için teşekkürler). Bazı platformlarda cURL, şifreyi gizlemeye çalıştığından, örneğin ps -efbir şifre yerine boşluk görmeniz muhtemeldir. Ancak, şifreyi bir komut satırı argümanı olarak iletmek yerine, cURL sss'inde tartışıldığı gibi cURL'nin doğrudan bir parola isteminde bulunması daha iyidir .


4
Curl'un verileri gizlemek için kendi savını başarıyla psyazdığı bir platformda olsanız bile , bu içeriğin savunmasız olduğu yere yazmaya başlamadan önce bir süre başlar.
Charles Duffy

Özet kimlik doğrulamaya ne dersiniz? Kıvrılma bunu varsayılan olarak kullanmaz mı?
rr

2
@rr Digest kimlik doğrulaması, marjinal açıdan daha iyidir, çünkü ortadaki adam saldırılarını önlemediğinden HTTPS kullanmaya devam edersiniz.
Dmitry Grigoryev

1
@rr StartSSL'nin çoğu tarayıcı tarafından güvenilir olmadığını nasıl düşünüyorsunuz ? Birçok Windows 95 veya Firefox 1.5 kullanıcısı olmasını bekliyor musunuz?
Hagen von Eitzen


24

Güvenli değil. Komut satırı parametreleri tüm kullanıcılar tarafından görülebilir.


4
@Dmitry Grigoryev ile birleşme en doğru cevap olabilir.
Francisco Tapia

1
Evet, itiraf etmeliyim ki sorunun büyük kısmını çok özledim.
Dmitry Grigoryev

komut yalnızca kullanıcı tarafından okunabilen bir komut dosyasının bir parçası olabilir ...
Pete

2
@ Yürütme programlarının komut satırları (bir komut dosyasından veya bir terminalde başlatılmış olsun) genellikle pskomut ve /procdosya sistemi aracılığıyla tüm kullanıcılar tarafından görülebilir . Komut hızlı bir şekilde tamamlanırsa, risk azalır, ancak hala oradadır.
RBerteig

2
@Pete Cevaplar özel değildir, birbirlerini tamamlarlar. Bu yüzden, ikinci cevabın ilk olarak açıklanan tehdidi atlatması tamam, bunun yerine onu tekrarlamak gereksiz olacak. Ve ifadeyi yanlış olarak adlandırmam çünkü mümkün olan her durumda doğru değil.
Dmitry Grigoryev

1

Bu, - netrc-file parametresi kullanılarak daha güvenli bir şekilde yapılabilir.

  1. 600 izne sahip bir dosya oluşturun

Örneğin: vi / root / dosyam

makine example.com

Kullanıcı adını gir

şifre ŞİFRE

Dosyayı Kaydet ve Kapat

  1. URL'ye Kullanıcı Adı ve Şifre ile erişmek için aşağıdakileri kullanın.

curl - netrc dosyası / root / dosyam http://example.com

  1. Bitti

0

HTTP şeması kullanılırken güvensizdir. Güvenli hale getirmek için HTTPS kullanmalısınız.

Parolanın komut geçmişinde görünmesini gizlemek için yalnızca kullanıcı adını sağlayın. Curl, komutta sağlanmadığı takdirde şifre ister.


HTTPS mevcut değilse yararlı bir cevap değildir. cURL bir "müşteri" dir.
mckenzm

0

Kısa cevap hayır ... ama ...

Sunucu tarafı seçeneği yoksa, güvenliği artırabilirsiniz.

  1. Eğer bu yerel intranet ise, yayın alanını izole edin ve WiFi veya herhangi bir radyo kullanmayın.
  2. Shameer'in dediği gibi, bir .netrc dosyası kullanın, değerleri kodun dışında tutun.
  3. Belleğin güvenli olduğuna güveniyorsan, çevre değişkeni kullan. $ PSWD.
  4. Bu otomasyon ise, root crontab'dan çalıştırın.
  5. ... bir kapta.
  6. ... şifreli bir diski olan bir sanal makineden.

Bunların hiçbiri, HTTP kullanan bir tarayıcıdan daha az güvenli değildir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.