URL https dengan parameter token: seberapa amankah itu?


89

Di situs kami, kami memberikan simulasi kepada pengguna berdasarkan informasi pribadi mereka (diberikan melalui formulir). Kami ingin mengizinkan mereka untuk kembali ke hasil simulasi nanti, tetapi tanpa memaksa mereka untuk membuat akun login / kata sandi.

Kami telah berpikir untuk mengirimi mereka email dengan tautan, dari mana mereka bisa mendapatkan kembali hasilnya. Tapi, tentu saja, kami harus mengamankan URL ini, karena data pribadi dipertaruhkan.

Jadi kami bermaksud untuk memberikan token (seperti kombinasi 40 karakter huruf dan angka, atau MD5 Hash) di URL dan menggunakan SSL.

Akhirnya, mereka akan menerima email seperti itu:

Hai,
Dapatkan kembali hasil Anda di https://www.example.com/load_simulation?token=uZVTLBCWcw33RIhvnbxTKxTxM2rKJ7YJrwyUXhXn

Apa yang Anda pikirkan? Apakah itu cukup aman? Apa yang akan Anda sarankan kepada saya untuk pembuatan token? Bagaimana dengan menyampaikan parameter URL dalam permintaan https?


Jawaban:


97

SSL akan melindungi parameter kueri saat transit; namun, email itu sendiri tidak aman, dan email dapat memantul di sejumlah server berapa pun sebelum mencapai tujuannya.

Juga tergantung pada server web Anda, URL lengkap mungkin masuk ke file log-nya. Bergantung pada seberapa sensitif datanya, Anda mungkin tidak ingin orang-orang TI Anda memiliki akses ke semua token.

Selain itu, URL dengan string kueri akan disimpan dalam riwayat pengguna Anda, memungkinkan pengguna lain dari mesin yang sama untuk mengakses URL.

Terakhir dan yang membuatnya sangat tidak aman adalah, URL dikirim di header Referer dari semua permintaan untuk sumber daya apa pun, bahkan sumber daya pihak ketiga. Jadi jika Anda menggunakan Google Analytics misalnya, Anda akan mengirimkan token URL ke Google dan semuanya kepada mereka.

Menurut saya ini ide yang buruk.


1
Saya tidak memikirkan tentang masalah pengarah HTTP, tetapi tautan url akan mengarahkan ke halaman hasil, itu bukan halaman yang tepat (tidak ada google analytics atau skrip pihak ketiga lainnya).
Flackou

5
Bukankah sebagian besar browser menghapus perujuk saat beralih dari HTTPS ke HTTP?
Kevin Mark

2
Ini mirip dengan tautan aktivasi pengguna (atau pengaturan ulang kata sandi), bukan? Bagaimana seharusnya kasus itu ditangani? Banyak situs web mengirim ulang url ke email, POST bukanlah pilihan karena harus dapat diklik. Terima kasih.
pinkpanther

3
jadi apa solusinya?
RT

1
bagaimana jika token di url tidak sama dengan token yang digunakan untuk permintaan api dan hanya bertahan satu jam, lalu apa ruginya?
pengguna1709076

13

Saya akan menggunakan cookie untuk itu. Alur kerja harus seperti ini:

  1. Pengguna datang ke situs Anda untuk pertama kalinya.
  2. Situs menyetel cookie
  3. Pengguna memasukkan data. Data disimpan di DB menggunakan beberapa kunci yang disimpan di cookie.
  4. Saat pengguna keluar, Anda mengirimi mereka email dengan tautan https:
  5. Saat pengguna kembali, situs menemukan cookie dan dapat menyajikan pengguna dengan data lama.

Sekarang, pengguna ingin menggunakan browser yang berbeda di komputer yang berbeda. Dalam hal ini, tawarkan tombol "transfer". Saat pengguna mengklik tombol ini, dia akan mendapatkan "token". Dia dapat menggunakan token ini di komputer lain untuk menyetel ulang cookie. Dengan cara ini, pengguna memutuskan seberapa aman dia ingin mentransfer token.


4

SSL mengamankan konten data saat transit, tetapi saya tidak yakin tentang URL-nya.

Terlepas dari itu, salah satu cara untuk mengurangi penyerang yang menggunakan kembali token URL tersebut adalah dengan memastikan setiap token hanya dapat digunakan sekali. Anda bahkan dapat mengatur cookie sehingga pengguna yang sah dapat terus menggunakan tautan tersebut, tetapi setelah akses pertama itu hanya akan berfungsi untuk seseorang yang memiliki cookie.

Jika email pengguna disusupi dan penyerang mendapatkan tautannya terlebih dahulu, Anda sudah disemprot. Tetapi pengguna juga memiliki masalah yang lebih besar.


11
Koneksi SSL diamankan sebelum URL dikirim.
David

1

E-mail pada dasarnya tidak aman. Jika ada yang bisa mengklik tautan itu dan mendapatkan datanya, Anda tidak benar-benar melindunginya.


Tepat tetapi banyak situs tidak peduli tentang itu dan mengirim login / kata sandi melalui surat. Tapi itu bukan alasan untuk meniru mereka ...
Flackou

Saya setuju tidak ada alasan untuk meniru mereka, tetapi mereka biasanya memberi tahu Anda untuk mengubah kata sandi setelah Anda masuk pertama kali.
Jason Punyon

1

Token itu aman saat diteruskan melalui SSL. Masalah yang akan Anda hadapi adalah bahwa ini tersedia untuk orang-orang (mereka yang tidak dimaksudkan untuk itu) dengan dapat melihat URL-nya.

Jika itu informasi pribadi seperti SSN, saya rasa saya tidak akan mengirim URL melalui email. Saya ingin mereka membuat nama pengguna dan kata sandi untuk situs tersebut. Terlalu mudah untuk mengkompromikan email dengan informasi semacam itu yang dipertaruhkan untuk Anda dan mereka. Jika akun seseorang dikompromikan, itu akan menjadi pertanyaan siapa sebenarnya kesalahan itu. Semakin aman semakin baik Anda dari sudut pandang CYA yang ketat.


1
Anda benar: URL akan tetap ada dalam riwayat browser misalnya
Flackou

0

Saya benar-benar tidak akan menganggap itu cukup aman untuk situasi di mana ada masalah privasi yang serius. Fakta bahwa Anda mengirimkan URL dalam email (mungkin teks jelas) sejauh ini merupakan tautan terlemah. Setelah itu adalah risiko serangan brute force pada token, yang (tidak memiliki struktur mekanisme otentikasi yang sebenarnya) cenderung lebih rentan daripada penyiapan nama pengguna dan sandi yang dibuat dengan baik.

Tidak ada masalah sama sekali dengan parameter dalam permintaan https, kebetulan.


Anda benar tentang risiko serangan brute force. Saya tidak melihat bagaimana kita dapat mencegah bot dari jenis serangan ini. Melarang IP yang "memaksa" tidak akan menjadi perlindungan yang memadai. Apakah Anda punya ide tentang hal ini?
Flackou

Sebenarnya, dengan jenis ruang kunci yang kita bicarakan, meletakkan if (this_ip_number_has_requested_an_invalid_token_today ()) sleep (5); dalam skrip load_simulation Anda akan menjadi perlindungan yang cukup sempurna. (Pembatasan tarif adalah salah satu fitur mekanisme otentikasi yang baik.)
chaos

Terima kasih atas jawaban anda. Tetapi saya pikir bot yang sama dapat dengan mudah mengambil IP berbeda yang membuat batas kecepatan IP tidak mencukupi. Apakah aku salah?
Flackou

Semua yang mendapatkannya adalah satu percobaan yang tidak tertunda per IP. Ruang alamat IP tidak begitu mudah tersedia sehingga itu membantu.
kekacauan

0

Memang, itu ide yang buruk. Anda akan menakut-nakuti keamanan dengan penggunaan yang mudah. Seperti yang dikatakan sebelumnya SSL hanya akan melindungi transfer informasi antara server dan browser klien dan hanya akan mencegah serangan perantara. Email sangat berisiko dan tidak aman.

Yang terbaik adalah otentikasi nama pengguna dan kata sandi untuk mengakses informasi.

Saya suka ide kue lebih atau kurang. Anda juga harus mengenkripsi informasi cookie. Anda juga harus membuat token dengan salt dan frase kunci ditambah $ _SERVER ['HTTP_USER_AGENT'] untuk membatasi kemungkinan serangan. Simpan sebanyak mungkin informasi tidak sensitif tentang klien di cookie untuk penggunaan verifikasi.

Frase kunci dapat disimpan dalam cookie untuk memudahkan penggunaan tetapi perlu diingat bahwa cookie juga dapat dicuri = (.

Lebih baik biarkan klien mengetikkan frase kunci yang dia berikan, yang juga disimpan di database bersama datanya.

Atau, kunci dapat digunakan jika orang tersebut menggunakan mesin lain yang berbeda dalam parameter $ _SERVER ['HTTP_USER_AGENT'] atau melewatkan cookie. Jadi cookie dapat ditransfer atau diatur.

Pastikan juga bahwa data sensitif dienkripsi dalam database. Kau tak pernah tahu ;)


-1

Anda tahu bahwa jika ada peretas yang mendapatkan akses ke database Anda, banyak informasi pribadi yang dapat diberikan secara bebas?

Setelah itu saya akan mengatakan bahwa ini tidak buruk sebagai ide. Saya tidak akan menggunakan MD5 atau SHA1 karena tidak terlalu aman untuk hashing. Mereka dapat "didekripsi" (saya tahu ini bukan enkripsi) dengan mudah.

Kalau tidak, saya mungkin akan menggunakan informasi kedua yang tidak akan dikirim melalui email semacam kata sandi. Alasannya cukup sederhana, jika seseorang mendapatkan akses ke email pengguna (cukup mudah dengan hotmail jika Anda tidak mematikan sesi Anda) dia akan memiliki akses ke semua informasi yang telah dikirim pengguna.

Perhatikan bahwa HTTPS akan mengamankan dan menyembunyikan data yang dikirim dari situs Anda ke pengguna akhir. Tidak ada yang lain, anggap saja sebagai terowongan yang aman. Tidak lebih tidak kurang.


Bagaimana sebenarnya hash SHA1 asin didekripsi dalam arti kata apa pun?
Eli

"Anda tahu bahwa jika ada peretas yang mendapatkan akses ke database Anda, banyak informasi pribadi yang dapat diberikan secara bebas?" Ya, tapi bukankah ini masalah untuk semua situs web ??
Flackou

@Flackou ya, tetapi jika Anda mendapatkan akses ke db paypal Anda tidak akan menemukan informasi kartu kredit yang disimpan dengan jelas, semuanya dienkripsi. @Eli: theregister.co.uk/2005/02/17/sha1_hashing_broken
Erick

-1

Dari apa yang saya pahami tentang ide Anda, secara teori seseorang dapat mengetikkan string 40 karakter acak atau hash MD5 dan mendapatkan detail orang lain. Meskipun hal ini mungkin sangat tidak mungkin, ini hanya perlu terjadi sekali.

Solusi yang lebih baik mungkin mengirimkan token kepada pengguna lalu meminta mereka memasukkan beberapa detail, seperti nama, kode pos, ssn, atau kombinasi keduanya.


5
SSN? Apakah kamu serius? Bagaimanapun, saya sarankan Anda menghitung berapa banyak 40 string acak karakter yang ada. Ini lebih dari sekedar "sangat tidak mungkin"
Eli

Anda benar, kita mungkin harus menambahkan parameter lain di url, seperti email (meskipun a..z + A..Z + 0..9 = 62 karakter, dan 62 ^ 40 adalah angka yang cukup besar).
Flackou

Guys, 62 ^ 40 jauh lebih banyak dari jumlah atom di alam semesta. Ini benar-benar tidak dapat diperkirakan.
Eli

1
Saya terkejut betapa banyak orang yang tidak dapat memahami skala angka-angka ini. Jika Anda menebak JUTA token per detik, kemungkinan besar matahari akan padam sebelum Anda terkena
Eli

4
Richard, sepertinya Anda menunjukkan apa yang biasanya disebut Paradoks Ulang Tahun ... bukan hanya jumlah kemungkinan kombinasi yang penting, tetapi berapa banyak dari kombinasi tersebut yang digunakan. Nah, dalam kasus ini, Anda perlu menggunakan sekitar 2 ^ 119 dari 62 ^ 40 kombinasi sebelum peluang menjadi signifikan.
erickson
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.