Bug Sensitive Data Exposure - CRUDPRO

Bug Sensitive Data Exposure

Dalam posting terbaru tentang otentikasi yang rusak, kami berbicara tentang penyerang yang mencari rute termudah ke aplikasi atau sistem. Dalam pengalaman kami, seringkali penyerang yang paling tidak terampil dari waktu ke waktu yang menghabiskan sebagian besar upaya untuk menemukan rute ini.

Sebagai penyerang ramah, kami melakukan hal yang sama selama simulasi musuh. Cari informasi tentang sistem klien di domain publik. Anda juga dapat menjelajahi aplikasi, server, halaman web, dan bahkan kantor klien untuk mengetahui apa saja yang terbuka untuk umum.

Kami (dan penyerang) dapat menemukan informasi sensitif yang dilindungi secara publik atau tidak semestinya. Misalnya, informasi pelanggan yang sensitif di penyimpanan publik di cloud, atau kata sandi yang dikirim dalam bentuk teks yang jelas melalui jaringan. Ini dikenal sebagai pengungkapan data sensitif.

Dampak

Menurut OWASP Top 10 List of Web Application Vulnerabilities pada tahun 2017, serangan yang memulihkan data sensitif telah menjadi "serangan paling umum dan berpengaruh" dalam beberapa tahun terakhir. Dampak ini berkisar dari kompromi pada akun pengguna individu dan data yang mereka pegang hingga pelanggaran data publik tingkat tinggi, yang serius bagi pemangku kepentingan dan perusahaan yang bertanggung jawab untuk melindungi data. Ini memiliki dampak yang besar.

Jadi bagaimana Anda bisa mencegah pelanggaran semacam ini terjadi di aplikasi web Anda?

Ketahui data Anda — apa yang Anda miliki dan di mana Anda memilikinya Sebelum Anda dapat melindungi data Anda, Anda perlu memahami bagaimana Anda mengumpulkannya, di mana Anda menyimpannya, dan bagaimana Anda memindahkannya. Anda juga perlu menentukan data mana yang dianggap sensitif. Ini bisa menjadi canggung untuk organisasi kecil dan bisa sangat sulit untuk organisasi besar. Dalam melakukannya, Anda perlu mengingat perbedaan antara berbagai jenis data sensitif yang Anda miliki.

  • Data untuk dikumpulkan, seperti catatan pribadi dan keuangan klien
  • Data yang digunakan untuk mengakses data lain, seperti username dan password.
  • Informasi tentang sistem yang dapat dieksploitasi oleh penyerang, seperti panduan pengguna untuk aplikasi teknis dan versi perangkat lunak.

Pemahaman data ini harus menjadi pendekatan jangka panjang dan permanen, bukan proyek atau persyaratan jangka pendek. Organisasi kecil yang bekerja pada platform terbatas mungkin memiliki pemahaman yang baik tentang di mana dan apa data tersebut pada titik waktu tertentu, tetapi tidak begitu imajinatif untuk memahami betapa rumitnya data tersebut. Tidak diperlukan. Bahkan perusahaan yang cukup besar memiliki pengetahuan yang lengkap. Sebaliknya, ini adalah upaya berkelanjutan dan perlu dikomunikasikan dengan cara kita memikirkan dan menangani data.

Mari kita mulai dengan hal-hal sederhana. Kata sandi pengguna, data pribadi, kekayaan intelektual, dan daftar klien adalah contoh informasi yang perlu dilindungi oleh semua organisasi.

Data keuangan, medis, dan data pribadi lainnya tentang seseorang dianggap rahasia, begitu juga Anda dan bisnis Anda. Anda harus mematuhi kerangka peraturan wilayah tempat Anda berbisnis, termasuk standar untuk menentukan dan mengelola data sensitif. Contohnya termasuk Peraturan Perlindungan Data Umum (GDPR) UE dan Otoritas Perilaku Keuangan (FCA) Inggris Raya.

Beberapa data, seperti kunci enkripsi pribadi dan kata sandi administrator domain, digunakan untuk melindungi data dan akses ke sistem. Tidak hanya harus disimpan dan dilindungi dengan benar, tetapi juga harus cukup kuat untuk menahan upaya peretasan.

Titik data untuk kasus sensitif yang tampaknya kecil dari data sensitif dapat dikurangi secara signifikan untuk menjadi bagian dari keberhasilan serangan.

Berikut adalah contoh simulasi:

  • Halaman di situs web perusahaan dengan nama dan foto semua karyawan. Nama file foto-foto ini termasuk nama pengguna orang-orang di foto. Kami telah berhasil menggunakan nama pengguna ini dalam serangan menebak kata sandi terhadap VPN perusahaan kami.
  • Bucket Amazon Web Services S3 (sumber daya penyimpanan cloud publik) yang berisi foto paspor Anda dan tidak memerlukan autentikasi.
  • Ketika pengidentifikasi unik universal (nomor unik yang digunakan untuk tujuan identifikasi) bocor dari satu bagian aplikasi dan digunakan untuk mengirim permintaan ke bagian lain dari aplikasi yang sama, data yang lebih sensitif akan dikembalikan.

Itu selalu merupakan praktik terbaik untuk mengekspos informasi sesedikit mungkin sehingga berbagai jenis pengguna dapat mengakses informasi dengan hanya melakukan tindakan yang secara eksplisit diperlukan.

Mari kita mulai

Setelah Anda memahami jenis data yang paling perlu Anda lindungi dan bagaimana data tersebut saat ini diproses, Anda dapat mulai meningkatkannya.

Ini bisa menjadi tugas yang menakutkan, tetapi kapan pun Anda dapat mengabdikan diri untuk itu akan membantu. Pikirkan saja tentang masalah ini dan buat perubahan kecil untuk maju.

Ingatlah bahwa keamanan yang baik bukanlah proyek, tetapi tugas berulang yang berkelanjutan untuk memperbaiki keadaan. Oleh karena itu, bagilah pekerjaan untuk melindungi data Anda menjadi bagian-bagian yang lebih kecil yang lebih mudah dikelola.

Saat melihat setiap jenis data, tanyakan pada diri Anda pertanyaan-pertanyaan berikut:

  • Di mana itu disimpan?
  • Bagaimana itu dilindungi?
  • Siapa yang dapat mengaksesnya dan bagaimana caranya?
  • Bagaimana itu akan dibagikan?
  • Bagaimana Anda diaudit?
  • Bagaimana itu akan dihapus?

Misalnya, jika informasi pribadi dan keuangan pelanggan disimpan dalam database, bagaimana Anda melindunginya dari siapa pun yang mengaksesnya? Anda perlu memastikan bahwa Anda memiliki perlindungan yang tepat, bahwa akses tersebut diautentikasi, dan hanya mereka yang secara eksplisit membutuhkan akses yang dapat mengaksesnya. Anda juga perlu mempertimbangkan cara memodifikasi atau menghapus catatan database dengan aman.

Memindahkan data juga menjadi pertimbangan penting. Jika data sensitif dikirim dalam bentuk teks yang jelas, Anda perlu memikirkan kembali mengapa dan siapa yang dapat melihatnya. Misalnya, jika data sensitif dipindahkan tidak terenkripsi di dalam jaringan, penyerang yang mengakses bagian jaringan dapat mengumpulkan informasi tersebut dengan memantau lalu lintas. Di tempat kerja klien, Anda mungkin melihat data pribadi sensitif yang dikirim melalui email dalam spreadsheet. Apakah ini risiko yang dapat diterima untuk organisasi Anda?

Anda juga perlu mempertimbangkan mekanisme yang Anda gunakan untuk melindungi data Anda dan apakah mereka cocok untuk tujuan Anda. Misalnya, seberapa kuat solusi enkripsi yang Anda pilih dan di mana kunci pribadi Anda disimpan? Apakah algoritme yang digunakan untuk menyandikan kata sandi cukup kuat untuk mempersulit penyerang untuk memulihkan kata sandi menggunakan alat cracking? Beberapa pertanyaan ini mungkin sulit untuk dijawab. Keamanan adalah area yang bergerak cepat, dan keputusan di sini perlu ditangani saat serangan berkembang. Mungkin bermanfaat untuk mendapatkan saran ahli.

Prinsip dan langkah praktis

Jangan tersinggung. Melindungi data sensitif bukanlah masalah yang tidak dapat dikelola, jika Anda tetap berpegang pada prinsip-prinsip utama berikut:

  • Saya akan melakukan yang terbaik untuk memahami data
  • Jangan mengumpulkan data kecuali diperlukan
  • Jangan mempublikasikan data kecuali Anda memiliki alasan yang bagus
  • Hapus data yang tidak lagi Anda perlukan

Langkah-langkah praktis terpenting yang dapat Anda ambil untuk membuat data sensitif Anda lebih aman adalah:

  • Gunakan enkripsi untuk melindungi perangkat fisik karyawan seperti ponsel dan laptop
  • Pastikan aplikasi Anda selalu disetel ke Secure HTTP Protocol (HTTPS) secara default. Ini memastikan bahwa data yang dikirim antara browser pengguna dan aplikasi selalu dienkripsi.
  • Untuk hash kata sandi seperti bcrypt, scrypt, dan argon2, gunakan algoritma yang kuat yang terdiri dari faktor kerja yang sesuai. Simpan hash di mesin yang terkunci
  • Lindungi data Anda dengan enkripsi siap pakai yang terbukti. Jangan mencoba mengenkripsi diri sendiri karena sangat sulit untuk melakukannya dengan benar

Melibatkan pemangku kepentingan utama dan staf teknis mungkin akan membantu dalam mengadakan lokakarya tentang pertanyaan-pertanyaan spesifik. Misalnya:

  • Lihatlah mekanisme penyimpanan dan transmisi data dari sudut pandang penyerang. Di mana penyerang dapat mencari data tersebut, dan bagaimana jika mereka menemukannya?
  • Bagaimana jika penyerang menemukan pijakan di jaringan melalui serangan injeksi atau kerentanan lainnya? Jika Anda memiliki data terenkripsi atau hash kata sandi, seberapa mudahkah mendekripsi atau mendekodekannya? Bagaimana Anda tahu apa yang terjadi?
  • Apa yang bisa dilihat penyerang sebagai pengguna itu jika penyerang masuk ke akun pengguna standar yang terdiri dari kata sandi yang lemah? Apakah mungkin untuk melihat lalu lintas tidak terenkripsi yang berjalan melalui jaringan? Bisakah mereka meningkatkan hak istimewa mereka? Bisakah kerentanan lain digunakan untuk membangun rute ke data sensitif?

Beberapa pertanyaan ini, terutama tentang perilaku penyerang, mungkin sulit untuk dijawab. Anda tidak bisa hanya mengandalkan pendekatan berbasis risiko tradisional. Ini karena tidak membentuk model perilaku penyerang yang realistis. Selain itu, pengujian penetrasi standar tidak mengungkapkan bahwa kerentanan, kesalahan konfigurasi server, atau rantai perangkat lunak yang tidak ditambal dapat menyebabkan pelanggaran.

Simulasi musuh menggunakan teknik yang sama seperti peretas kriminal dan ancaman persisten tingkat lanjut untuk secara realistis mensimulasikan pelanggaran data, pencurian informasi, dan banyak lagi.

Jika Anda menginginkan obrolan tidak wajib tentang cara membantu melindungi data sensitif, silakan hubungi kami.

0 Response to "Bug Sensitive Data Exposure"

Post a Comment

Iklan Atas Artikel

Iklan Tengah Artikel 1

Iklan Tengah Artikel 2

Iklan Bawah Artikel