apakah boleh menggunakan URL acak dan bukan kata sandi? [Tutup]


12

Apakah dianggap "aman" untuk menggunakan URL yang dibuat dari karakter acak seperti ini?

http://example.com/EU3uc654/Photos

Saya ingin meletakkan beberapa file / galeri gambar di server web yang hanya dapat diakses oleh sekelompok kecil pengguna. Perhatian utama saya adalah bahwa file tidak boleh diambil oleh mesin pencari atau pengguna yang ingin tahu yang melihat-lihat situs saya.

Saya telah menyiapkan file .htaccess, hanya untuk memperhatikan bahwa mengklik http://user:pass@url/tautan tidak berfungsi dengan baik dengan beberapa browser / klien email, mendorong dialog dan pesan peringatan yang membingungkan pengguna saya yang tidak terlalu komputer-savy.


Tidak. Anda dapat menggunakan ini, tetapi bukan sebagai satu-satunya atau mekanisme otentikasi utama.
Andrew Smith

1
Saya telah mencoba ini sebagai percobaan berkali-kali, dan setiap kali tautan berakhir di mesin pencari. Saya tidak tahu caranya, tetapi saya tahu itu terjadi.
David Schwartz

Anda mungkin ingin mengonfigurasi SSL untuk menghentikan peringatan, Anda bisa mendapatkan sertifikat gratis dari startssl.com dan SSL tidak lagi intensif secara komputasi (asalkan dikonfigurasi dengan benar).
Hubert Kario

Pertanyaan ini adalah contoh klasik "Tidak Konstruktif". Kami tidak tahu seberapa besar Anda menghargai keamanan gambar Anda. Satu-satunya cara Anda dapat mengomunikasikan pentingnya keamanan adalah dengan metodologi otorisasi yang Anda terapkan untuk melindungi akses ke foto-foto itu. Yang Anda dapatkan adalah "argumen debat" dalam bentuk "Jawaban". Tetapi tidak satu pun dari mereka yang memiliki survei lengkap tentang keamanan modern dan implikasi teknis. Anda harus membaca tentang metode keamanan yang disediakan oleh platform Anda dan menilai nilai masing-masing untuk situasi Anda; jika Anda memiliki pertanyaan lebih lanjut setelah Anda selesai melakukannya, tanyakan lagi.
Chris S

Jawaban:


17

Apakah itu "oke" atau tidak tergantung pada seberapa sensitif gambar itu.

Jika Anda tidak menggunakan SSL, URL, HTML, dan gambar itu sendiri akan di-cache di komputer pengguna Anda. Ini bisa bocor tapi saya akan menganggapnya tidak mungkin.

Bilah alat browser, terutama yang dibuat oleh perusahaan yang menjalankan perayap, seperti Alexa dan Netcraft, dapat melaporkan URL yang dikunjungi kembali ke situs induknya, siap untuk bot yang akan datang dan merangkak nanti.

Otentikasi yang tepat seperti HTTP auth atau variabel POST seharusnya tidak dapat di-cache dengan cara ini atau dilaporkan kembali ke situs web induk mana pun.

Teknik lain adalah dengan menggunakan URL yang unik dan berumur pendek. Dengan begitu, bahkan jika mereka bocor, tidak masalah. Tentu saja, Anda harus terus memperbarui pengguna baru URL yang sah.


+1 untuk menyebutkan bilah alat peramban.
Hubert Kario

23

Tidak, tidak juga, ini hanya keamanan melalui ketidakjelasan yang tidak ada keamanan sama sekali. Apa pun yang dapat diakses langsung dari internet tanpa beberapa bentuk perlindungan nyata akan ditemukan, diindeks dan di-cache.


10
Bukankah semua kata sandi hanya keamanan melalui ketidakjelasan?
Winston Ewert

4
@ WinstonEwert: Kata sandi itu sendiri tidak ada hubungannya dengan keamanan melalui ketidakjelasan yang berkaitan dengan kerahasiaan desain / implementasi. Dalam kasus misalnya Apache auth dasar, desain / implementasi sepenuhnya terbuka untuk semua orang.
user9517

10
omong kosong - semuanya keamanan melalui ketidakjelasan. Intinya adalah bahwa untuk sampai ke sana Anda memerlukan sepotong informasi yang tidak mungkin dapat ditebak. Ungkapan "Keamanan melalui Ketidakjelasan" secara luas disalahgunakan. Sepotong acak URL sama persis dengan menempatkan "kata sandi" di URL. Satu-satunya pertanyaan adalah - siapa yang bisa melihat itu, dan jawaban yang saya berikan dalam komentar saya adalah "proxy menengah, ditambah itu http jadi siapa pun yang bisa menyelinap"
Bron Gondwana

1
Satu kesalahan (atau kembali ke konfigurasi default) di konfigurasi apache dan direktori Anda menampilkan indeks dengan semua file dan direktori di telapak tangan Anda, tidak terlalu banyak dengan kata sandi.
Hubert Kario

4
Anda mengatakan bahwa keamanan melalui ketidakjelasan "berhubungan dengan kerahasiaan desain / implementasi". Namun yang jelas, URL acak tidak menghubungkan kerahasiaan desain / implementasi. Dengan demikian, URL acak, apa pun kesalahannya, tidak dapat diklasifikasikan sebagai keamanan melalui ketidakjelasan.
Winston Ewert

6

Mereka akan masuk setiap proxy di sepanjang jalan. Anda akan aman dari pengguna listrik dan mesin pencari yang penasaran kecuali seseorang benar-benar menerbitkan tautan tersebut.

Dan berhati-hatilah dengan keacakan generator Anda tentu saja.

Saya kira Anda tidak mencari keamanan super tinggi di sini.


Jika seseorang menerbitkan URL, tidak ada yang menahannya untuk menerbitkan kata sandi. Otentikasi oleh pengetahuan sebagai faktor selalu dapat "diakali" seperti ini.
Manuel Faux

@ManuelFaux: Tentu, jika disengaja. Tetapi bisa juga kebetulan. Misalnya, ia dapat menggunakan alat yang memeriksa URL yang ia kunjungi untuk melihat apakah URL tersebut dilaporkan berbahaya. Alat tahu kata sandi seharusnya dirahasiakan. Mereka tahu parameter dalam URL bisa sensitif. Tetapi mereka tidak tahu bahwa jalur di URL benar. (Misalnya, pengarah http .)
David Schwartz

5

URL samar berguna untuk unduhan sekali pakai tetapi tidak memberikan perlindungan nyata. Anda perlu menyadari bahwa tidak semua bot menghormati file robots.txt, jadi jika ada tautan di mana saja di dalam situs Anda yang mengarah ke folder yang disamarkan, itu akan diindeks oleh beberapa mesin pencari dan sekali itu dimulai tidak akan kembali.

Saya sarankan menggunakan sistem otentikasi berbasis .htaccess sederhana sebagai gantinya, atau di samping, apa yang Anda usulkan.


5

Saya ingin menambahkan yang lain, mungkin perspektif yang lebih menakutkan pada URL yang dikaburkan seperti contoh ini. Bahkan jika URL Anda tidak dibagikan secara tidak sengaja, URL tersebut dapat dikirimkan ke mesin pencari dengan:

  • ISP pengunjung. Kunjungan HTTP dikumpulkan, didata dan kadang-kadang bahkan langsung dijual kepada pihak ketiga oleh ISP.
  • Penyimpanan Cloud pengunjung. Ada sejumlah layanan yang menyimpan bookmark dan riwayat secara gratis untuk disinkronkan di seluruh pemasangan browser. Kecuali mereka melakukan pra-enkripsi data seperti yang dilakukan Mozilla, praktik penambangan data yang sama dapat diterapkan.

YMMV.


oh ya - atau hanya dengan plugin peramban yang mencari situs terkait atau memungkinkan pengguna untuk berbagi catatan tentang halaman
Bron Gondwana

2

Di masa lalu saya menggunakan metode serupa untuk memungkinkan pengguna membuat ruang berbagi pada sistem manajemen dokumen. Konten yang dibagikan bukan rahasia besar sehingga sistem tidak harus sangat aman.

Saya baru saja membuat setiap URL pengguna berisi cap waktu kedaluwarsa dan MD5 dari email mereka.

JADI URL itu terlihat seperti:

http://my-url.com/1343689677-cba1f2d695a5ca39ee6f343297a761a4/

dengan di atas, jika pengguna memasukkan email user@gmail.com sebelum 30 Juli mereka akan baik-baik saja.

Bukan keamanan kelas militer tetapi melakukan pekerjaan.


0

Ini berbagi kerentanan yang sama dengan menyimpan sessionID di URL. Seseorang dapat secara tidak sengaja menyalin-tempel tautan tersebut ke orang lain, lupa menyensornya dalam tangkapan layar, atau membiarkan seseorang mencarinya, karena itu bukan tanda bintang seperti kata sandi.

Juga, jika beberapa konten dilindungi kata sandi, dengan masuk Anda tahu itu rahasia. Jika Anda mendapatkan tautan, Anda dapat dengan mudah melupakannya.

Hal lain adalah menghapus hak pengguna. Anda dapat menghapus pengguna, sehingga ia tidak bisa lagi masuk, tetapi dengan tautan Anda harus mengubah semuanya, dan mengirim semua orang (kecuali pengguna yang dihapus) URL baru.

Saya pikir tidak buruk jika ini hanya gambar. Tetapi jika ini adalah beberapa gambar yang Anda benar-benar tidak ingin bagikan;) maka saya sarankan Anda untuk menggunakan kata acak yang lebih panjang, lebih seperti gambar yang disajikan.

EDIT: Tambahkan? DO_NOT_SHARE_THIS_LINK ke URL: http://example.com/DO_NOT_SHARE_THIS_LINK/EU3uc654-this-should-be-longer/Photos?DO_NOT_SHARE_THIS_LINK

Itulah yang misalnya dilakukan Kongregate ketika menyematkan game yang dihosting di tempat lain (itu menempatkan kredensial autentik di url frame). BTW, Kongregate juga menggunakan tautan akses tamu untuk game yang tidak diterbitkan, seperti yang Anda inginkan.


Sebenarnya ini jauh lebih buruk daripada ID sesi, karena sesi berakhir setelah beberapa waktu. Mesin pencari mengambil ID sesi login biasanya berakhir menyajikan tautan mati / tidak masuk sesi dalam hasil. Atau, jika server tidak peduli, itu mungkin menyinkronkan sesi banyak pengguna dan ketika salah satu dari mereka masuk, mereka semua melakukannya. Bagaimanapun, tidak seburuk URL login permanen :-)
korkman

Tentu saja itu lebih buruk, dan Anda juga dapat mengingat IP dalam sesi karena Anda harus masuk terlebih dahulu untuk mendapatkan sessid di url, dan kemudian Anda dapat menghancurkan sesi jika IP berubah.
Markus von Broady
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.