Kredensial Otentikasi HTTP Dasar diteruskan dalam URL dan enkripsi


250

Saya memiliki pertanyaan tentang kredensial HTTPS dan HTTP Authentication.

Misalkan saya mengamankan URL dengan Otentikasi HTTP:

<Directory /var/www/webcallback>
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /var/www/passwd/passwords
Require user gooduser
</Directory>

Saya kemudian mengakses URL itu dari sistem jarak jauh melalui HTTPS, meneruskan kredensial di URL:

https://gooduser:secretpassword@www.example.com/webcallback?foo=bar

Akankah nama pengguna dan kata sandi dienkripsi secara otomatis SSL? Apakah hal yang sama berlaku untuk GET dan POST? Saya mengalami kesulitan menemukan sumber yang kredibel dengan informasi ini.



Namun pertanyaan yang sangat lama: pendekatan ini telah ditinggalkan oleh ietf.org/rfc/rfc3986.txt : "Penggunaan format" user: password "di bidang userinfo sudah ditinggalkan."
Madbreak

Jawaban:


237

Akankah nama pengguna dan kata sandi dienkripsi secara otomatis SSL? Apakah hal yang sama berlaku untuk GET dan POS

Ya ya ya.

Seluruh komunikasi (simpan untuk pencarian DNS jika IP untuk nama host belum di-cache) dienkripsi ketika SSL sedang digunakan.


25
+1. GET dan POST, termasuk url, dienkripsi. Saya hanya akan menambahkan - alat seperti data pembakar dan Tamper dapat menampilkan hasil yang tidak dienkripsi hanya karena mereka adalah bagian dari browser dan karenanya dapat mencegat permintaan sebelum dienkripsi. Setelah dikirim melalui kabel, semuanya dienkripsi.
Sripathi Krishnan

21
Agar jelas, semuanya kecuali domain dienkripsi. Jika ada yang tersandung di ini dan ingin jawaban yang lebih rinci, lihat answers.google.com/answers/threadview/id/758002.html
rcourtna

7
Demi kelengkapan, " Internet Explorer tidak mendukung nama pengguna dan kata sandi di alamat situs Web (HTTP atau HTTPS URL) " Sepertinya hanya Internet Explorer versi 3.0 hingga 6.0 yang mendukung sintaks berikut untuk HTTP atau URL HTTPS: http (s): //username:password@server/resource.ext Catatan: Perubahan perilaku default ini tidak memengaruhi protokol lain. Misalnya, Anda masih bisa memasukkan informasi pengguna dalam URL FTP setelah Anda menginstal pembaruan keamanan 832894.
Luke

jawaban ini tidak mengandung sumber yang kredibel atau penjelasan lebih lanjut.
Jens Piegsa

26

Ya, itu akan dienkripsi.

Anda akan memahaminya jika Anda cukup memeriksa apa yang terjadi di balik layar.

  1. Browser atau aplikasi pertama-tama akan memecah URL dan mencoba untuk mendapatkan IP host menggunakan DNS Query. yaitu: Permintaan DNS akan dilakukan untuk menemukan alamat IP domain (www.example.com). Harap dicatat bahwa tidak ada informasi lain yang akan dikirim melalui permintaan ini.
  2. Browser atau aplikasi akan memulai koneksi SSL dengan alamat IP yang diterima dari permintaan DNS. Sertifikat akan dipertukarkan dan ini terjadi di tingkat transportasi. Tidak ada informasi level aplikasi yang akan ditransfer pada saat ini. Ingat bahwa otentikasi Dasar adalah bagian dari HTTP dan HTTP adalah protokol tingkat aplikasi. Bukan tugas layer transport.
  3. Setelah membuat koneksi SSL, sekarang data yang diperlukan akan diteruskan ke server. yaitu: Path atau URL, parameter dan otentikasi dasar nama pengguna dan kata sandi.

-5

Belum tentu benar. Ini akan dienkripsi pada kabel tetapi masih mendarat di log teks biasa


17
Server Web apa yang mencatat nama pengguna dan kata sandi dari permintaan? Itu akan menjadi server web yang tidak aman.
Andrew Barber

1
Ya ini tidak benar. Mungkin memungkinkan untuk menginstruksikan apache untuk mencatat informasi ini, tetapi sudah pasti tidak melakukannya secara default.
DougW

27
@Brandon mungkin berpikir "dalam URL" yang dimaksud dalam string kueri (misalnya,? User = bob & pw = 123hackmeplz). Itu bisa berakhir di log server.
Mike Graf

5
Terkait: "Ketika Anda memanggil URL itu pada klien dengan curl misalnya, nama pengguna dan kata sandi akan terlihat jelas pada daftar proses dan mungkin muncul di file bash history." - stackoverflow.com/a/4981309
Hawkeye Parker

1
@ zb226 si penanya secara khusus menyebutkan memasukkan kredensial di URL.
Lambart
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.