Apa vektor serangan untuk kata sandi yang dikirim melalui http?


10

Saya mencoba meyakinkan pelanggan untuk membayar SSL untuk situs web yang memerlukan login. Saya ingin memastikan bahwa saya benar memahami skenario utama di mana seseorang dapat melihat kata sandi yang sedang dikirim.

Pemahaman saya adalah bahwa di salah satu hop di sepanjang jalan dapat menggunakan penganalisa paket untuk melihat apa yang sedang dikirim. Hal ini tampaknya mengharuskan peretas (atau malware / botnet) mereka berada di subnet yang sama dengan salah satu hop yang diperlukan paket untuk sampai di tujuannya. Apakah itu benar?

Dengan asumsi beberapa rasa persyaratan subnet ini benar, apakah saya perlu khawatir tentang semua hop atau hanya yang pertama? Yang pertama saya jelas bisa khawatir jika mereka berada di jaringan Wifi publik karena siapa pun bisa mendengarkan. Haruskah saya khawatir tentang apa yang terjadi di subnet bahwa paket akan melakukan perjalanan melintasi luar ini? Saya tidak tahu banyak tentang lalu lintas jaringan, tetapi saya akan menganggapnya mengalir melalui pusat data dari operator besar dan tidak ada banyak vektor serangan menarik di sana, tapi tolong perbaiki saya jika saya salah.

Apakah ada vektor lain yang perlu dikhawatirkan di luar seseorang yang mendengarkan dengan penganalisa paket?

Saya seorang noob jaringan dan keamanan, jadi silakan luruskan jika saya menggunakan terminologi yang salah dalam semua ini.


jika situs berisi rincian perbankan atau keuangan, informasi pribadi, maka SSL merupakan prasyarat untuk langkah login. Jika bisa diretas dengan mudah, itu akan terjadi.
Mitch Wheat

2
Saya tidak melihat alasan untuk menutup ini. Ini terkait pemrograman.

Siapa pun yang mengunjungi situs ini dari titik akses bersama akan diambil kreditnya, bahkan jika AP menggunakan enkripsi itu sendiri (karena semua orang di sana juga memiliki kunci). Jika orang menggunakan kembali kredibilitas mereka di situs lain, maka itu merupakan masalah.
Aaron

Jawaban:


3

Sesuatu yang perlu dicatat yang belum disebutkan orang lain di sini adalah beberapa browser menyimpan data formulir Anda. Perilaku default pada situs SSL biasanya adalah untuk tidak menembolok apa pun kecuali Anda memilih "simpan kata sandi saya". Biasanya bidang kata sandi tidak melakukan cache, tetapi saya telah melihat beberapa keanehan (biasanya info kartu kredit, yang saya tahu sebenarnya bukan topik pertanyaan).

Hal lain yang perlu diperhatikan adalah Enkripsi SSL dimulai pada jabat tangan TCP. Setelah di bawah SSL Anda tidak dapat membedakan HTTP over SSL dari FTP over SSL (selain dari asumsi yang dibuat melalui nomor port).

Anda juga tidak dapat membedakan permintaan login dari permintaan "Saya hanya menjelajah", ini mengaburkan aliran halaman dari calon peretas dan juga memastikan tidak hanya data kata sandi Anda yang aman, tetapi riwayat penelusuran / data cookie / / dan informasi pribadi yang sejalan dengan akun Anda.

Semua-dalam-semua jika Anda menghilangkan serangan man-in-the-middle dari spektrum Anda mengurangi banyak potensi serangan, itu tidak berarti bahwa situs Anda 'aman'. Juga kebijakan zonasi akan membantu melindungi Anda dari serangan XSS karena Anda akan melakukan perubahan zona jika pengguna Anda diarahkan kembali keluar dari situs Anda.


"asumsi dibuat melalui nomor port"? Bukankah port biasanya 443 untuk SSL (baik HTTP atau FTP)?
tukang bata

4

Data rentan di mana saja di sepanjang rute, bukan hanya tahap pertama atau terakhir. Sangat mungkin bahwa sistem yang terlibat dalam transfer mencari nama pengguna, kata sandi, dan data sensitif lainnya. Oleh karena itu, data sensitif hanya boleh berjalan di atas tautan yang dijamin sepenuhnya dan tentu saja untuk apa SSL itu. Bergantung pada data apa yang terlibat, mungkin ada undang-undang setempat yang menentukan SSL.


Bisakah itu melewati subnet di mana konsumen memiliki akses atau hanya melewati tulang punggung operator utama dalam hal mana kita harus berasumsi bahwa peretas telah retak mengatakan pusat ops Level 3 (hanya misalnya)?
KevinM

Biasanya saya tidak berharap untuk melakukan perjalanan melalui jaringan konsumen tetapi ingat bahwa sistem apa pun dapat dikompromikan. Meskipun kita harus dapat mengharapkan ISP dan sistem operator menjadi lebih aman, kita juga tahu bahwa banyak yang telah dikompromikan di masa lalu. Tidak ada sistem atau jaringan yang kebal terhadap peretasan, karenanya kebutuhan untuk hal-hal seperti SSL. Bahkan bisa menjadi karyawan ISP yang mengumpulkan informasi yang bepergian melalui jaringan. Hanya diperlukan satu ketukan pasif sederhana.
John Gardeniers

1
Ini juga bisa menjadi agen pemerintah favorit Anda yang memasang keran dengan bantuan ISP Anda ... Jika Anda menganggap bahwa serangan itu atau bukan terserah Anda.
pehrs

2

Ada server proxy yang mungkin menyimpan data.

Namun ada juga kewajiban untuk menjaga keamanan kata sandi pengguna. Banyak pengguna menggunakan kumpulan kata sandi terbatas, jadi situs yang tidak aman mungkin membahayakan kata sandi bank rumah mereka.


1
Ya, poin kedua Anda adalah yang penting. Saya pikir itu sesuai untuk situs web untuk tidak bertindak seolah-olah mereka adalah pusat dunia pengguna.

1

Analisis Anda masuk akal, IMHO.

Hal yang perlu diperhatikan, saya kira, adalah mungkin ada cache di jalan Anda. Jadi mungkin saja permintaannya dicatat di suatu tempat (terutama jika loginnya lebih dari GET, yang akan mengerikan).

Mungkin hal yang perlu dipertimbangkan adalah bahwa sebagian besar akses jaringan terjadi di daerah di mana ada banyak orang lain di jaringan yang sama. Pekerjaan / Uni / Sekolah menjadi contoh utama. Di rumah Anda bisa berpendapat bahwa itu tidak terlalu berisiko, karena hanya jalan setapak yang perlu Anda perhatikan.

Tapi sungguh, tidak ada pertanyaan di sini. Anda menggunakan SSL saat masuk. Mungkin argumen paling menarik untuk pria tersebut adalah bahwa hal itu membuat situs web Anda tampak lebih dapat dipercaya, karena - idealnya - masyarakat umum tidak akan pernah masuk ke situs yang tidak memiliki layar masuk berbasis SSL .

Tapi mari kita bersikap realistis. Hampir pasti vektor serangan ini bukan cara sistem atau penggunanya akan dikompromikan.

HTH.


1

Saya bisa setuju dengan renungan KevinM untuk menjawab pertanyaannya sendiri, dan John Gardeniers menunjuk ke arah yang benar. Saya juga harus setuju dengan apa yang dikatakan oleh sutra, di, "idealnya - masyarakat umum tidak akan pernah masuk ke situs yang tidak memiliki layar masuk berbasis SSL.", Dan menunjukkan bahwa ini, bagaimanapun, bukan kasus kontemporer sama sekali.

Saya tidak setuju dengan nada halus (mungkin tidak disengaja), yang mengarah ke persepsi di mana-mana bahwa, "masyarakat umum", adalah bodoh. Klien KevinM jelas tidak memiliki konsep kebutuhan akan SSL, dan itu adalah orang biasa. Mereka tidak bodoh, mereka tidak tahu. Untuk mengatakan, "Anda membutuhkan ini", akan melegalkan respons, "Saya telah hidup x tahun tanpa itu, dan saya akan hidup x lebih baik", atau mungkin bahkan tanggapan yang lebih buruk, "Saya benci diberitahu apa yang saya butuhkan . " Jadi berhati-hatilah!

Kekhawatiran Anda sah, Kevin. Pelanggan Anda memang membutuhkan sertifikat SSL. Saya pikir kepedulian Anda yang sebenarnya adalah bagaimana cara menjualnya. Bukan hanya login pengguna yang perlu dikhawatirkan, tetapi login administrator dan operator yang juga akan mendapat manfaat dari dilindungi oleh SSL.

Ya, ada hal-hal lain yang perlu diperhatikan dalam hal ini, bahkan lebih dari mengendus paket, seperti XSS . Mereka banyak, dan didokumentasikan dengan baik .


Terima kasih Daniel. Saya pikir penting untuk tidak hanya memiliki aturan yang sewenang-wenang, tetapi untuk memahami apa yang memunculkan prinsip-prinsip yang kita miliki. Jadi saya ingin memastikan saya bisa mengartikulasikan ini dengan benar. Saya bisa meyakinkan pelanggan untuk mendapatkan SSL, untungnya!
KevinM

0

di seluruh rute yang diikuti oleh paket, jika lebih dari HTTP dapat diendus dan data dapat dilihat ... bahkan jika Anda menggunakan HTTP di Proxy seperti TOR ... menggunakan harvesting-attack, dll. seseorang dapat menipu Proxy untuk membocorkan paket data ... jadi jika ada sesuatu yang mendekati sensitif (kata sandi, detail pribadi, gambar pribadi, dll.) ... itu hanya cocok untuk mentransfernya melalui HTTPS.

Itu juga, bahkan HTTPS rentan dengan implementasi yang salah dan mereka adalah beberapa Serangan SSL yang berlaku atasnya ... masih dapat dihindari dengan implementasi yang hati-hati.

Tapi, menggunakan HTTP untuk teks biasa seperti mengundang bahkan anak-anak yang baru masuk / tidak mengendus-endus kata sandi.

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.