Apa tujuan @ (pada simbol) di URL sebelum domain?
Saya baru-baru ini menemukan serangan phishing baru yang menggunakan @simbol untuk membuat URL terlihat sah. Ini berjalan seperti ini:
Saya memiliki akun di totally-legit-site.comdan penyerang membuat situs phishing di IP-nya seperti 192.168.50.20. Kemudian, dia mengirimi saya pesan di situs tersebut, berisi tautan yang mirip http://[email protected]/account. Ini digunakan untuk mengelabui pengguna agar mengira ini adalah tautan ke situs yang sah.
Mengklik link ini, bagaimanapun, membuka halaman 192.168.50.20/accountdi browser saya (Google Chrome). Saya mencoba menambahkan hal-hal acak dengan @sebelum domain acak dan browser saya selalu menyelesaikan halaman dengan benar, membuangnya @. Jadi jika saya mencoba membukanya http://[email protected], saya berakhir di beranda Google.
Ini sangat menarik minat saya. Saya tidak dapat menemukan informasi apa pun tentang @di URL sebelum domain. Bagaimana ini disebut? Apakah ini beberapa barang usang dari tahap awal internet? Apakah ada beberapa server web yang dapat memproses bagian URL ini (dapat memodifikasi instance nginx saya untuk mengembalikan situs yang berbeda berdasarkan parameter ini akan keren)?
Jawaban
Sintaks ini digunakan untuk menentukan detail otentikasi tingkat protokol (nama pengguna, terkadang juga kata sandi) untuk menghubungkan ke 'otoritas'. Lihat misalnya RFC 3986 bagian 3.2.1 .
Saat digunakan dengan HTTP, kredensial dikirim dalam HTTP Authorization: header ; formatnya tergantung pada mekanisme otentikasi yang diminta oleh server, tetapi paling umum Basicotentikasi digunakan tanpa pemrosesan tambahan. Lihat RFC 7617 atau MDN .
Banyak server web dapat memverifikasi kredensial terhadap file 'htpasswd', LDAP, SQL atau database lain - misalnya untuk Nginx lihat auth_basic atau Apache httpd AuthType Basic .
Atau, verifikasi dapat dilakukan oleh aplikasi web itu sendiri karena dilakukan melalui header HTTP standar dan kode status. Lihat misalnya PHP (Tetapi agar ini berfungsi di Apache, Anda mungkin perlu mengaktifkan CGIPassAuthatau menggunakan trik penulisan ulang yang aneh, jika tidak, header Otorisasi tidak akan diteruskan ke runtime aplikasi.)
Autentikasi HTTP bawaan biasanya digunakan untuk API dan permintaan otomatis lainnya, karena tidak memerlukan interaksi pengguna, tidak memerlukan penyimpanan cookie atau status lain, dan tidak memerlukan pengetahuan cara memformat permintaan POST "masuk" (yang mana Anda perlu autentikasi berbasis <form>).
Ini juga merupakan metode otentikasi yang sama persis seperti yang digunakan oleh perintah berikut:
Sintaks yang sama juga berlaku untuk FTP dan banyak protokol lain yang menggunakan URL dan mendukung otentikasi - dalam semua kasus, mekanisme bawaan protokol tersebut digunakan.
Serangan di sini berfungsi karena otentikasi HTTP bersifat opsional dan dalam banyak kasus header HTTP tambahan diabaikan begitu saja oleh server web dan aplikasi web. Dan sebaliknya, browser tidak tahu apakah server akan meminta autentikasi sampai setelah permintaan dikirim.
Namun, serangan itu sama sekali bukan hal baru - sudah ada setidaknya sejak awal 2000-an. (Faktanya, di beberapa titik browser mulai memeriksa, dengan terlebih dahulu membuat permintaan tanpa auth untuk melihat apakah server akan membalas dengan 401 atau tidak. Jika server tidak meminta otentikasi, Chrome akan menyembunyikan nama pengguna dari bilah alamat untuk membuat domain sebenarnya lebih jelas, dan Firefox sebenarnya akan memperingatkan bahwa "Ini mungkin upaya untuk menipu Anda.")