Broken Authentication Saat Attacker Masuk Ke Aplikasi Web
Pada tulisan medium - Injection Attack explained dalam tulisannya menjelaskan tentang bagaimana aplikasi dapat dikelabui untuk menafsirkan data yang disediakan pengguna sebagai instruksi untuk melakukan operasi.
Namun, penyerang akan selalu mencari rute termudah untuk masuk. Jika mereka dapat langsung masuk ke aplikasi dan mengeksploitasi fungsi yang ada untuk mencuri data atau lebih buruk, maka mereka tidak perlu menghabiskan waktu mencari kerentanan kritis atau mencoba melewati firewall Anda.
Apa yang dimaksud dengan "Broken Authentication"?
Ini disebut pelanggaran otentikasi jika kemampuan login aplikasi dapat rusak atau dilewati dengan cara tertentu. Kegagalan otentikasi adalah entri dalam Daftar 10 Teratas Kerentanan Aplikasi Web Open Web Application Security Project (OWASP), karena ini adalah masalah yang sangat umum.
Penyebab mekanisme otentikasi yang rusak atau dilewati dapat berkisar dari yang sederhana hingga yang sangat teknis. Namun, kerentanan ini dapat dicegah dengan cara yang tepat dengan memasukkan pemikiran keamanan ke dalam proses desain.
Jenis Broken Authentication
Ada banyak cara untuk melewati otentikasi.Pertama, OWASP mendefinisikan otentikasi sebagai "rusak" jika tidak mengambil langkah-langkah dasar untuk mencegah penggunaan kata sandi yang tidak tepat dan upaya peretasan paksa. Mengelola kata sandi secara efektif untuk pengguna adalah bagian penting dalam membangun budaya keamanan yang baik.
Serangan tebak kata sandi brute force dapat berhasil bahkan jika kata sandi yang lemah tidak umum di aplikasi. Serangan tersebut menggunakan daftar kata sandi dan kombinasi nama pengguna atau kata sandi yang dikumpulkan dari pelanggaran data. Dengan alat yang siap pakai, Anda dapat secara otomatis mencoba ribuan kombinasi nama pengguna dan kata sandi.
Dalam beberapa kasus, ada cacat desain dalam sistem yang memungkinkan seseorang membuat akun tanpa melalui saluran biasa. Untuk mengambil contoh dari pekerjaan kami:
- Kode undangan akun di HTML halaman login. Ini memungkinkan kami untuk membuat akun istimewa.
- Aplikasi yang mengimplementasikan login berbasis nama pengguna/sandi dengan benar, tetapi memiliki logika yang salah untuk mengizinkan akses ke halaman sensitif meskipun upaya login gagal.
- Beberapa metode otentikasi. Salah satunya rentan terhadap serangan, sedangkan metode otentikasi lainnya rentan terhadap serangan.
- Kredensial login yang dikirim melalui koneksi tidak terenkripsi dapat ditangkap oleh penyerang
- Tidak dapat mengeluarkan pengguna dengan benar, sesi tetap aktif dan lebih rentan terhadap pembajakan
Bagaimana masalah ini terjadi?
Akar dari sebagian besar masalah Broken Authentication adalah desain atau pengelolaan fungsionalitas aplikasi.
Saat membangun aplikasi, sangat penting untuk memperhatikan fitur-fitur yang dapat diakses oleh berbagai jenis pengguna, baik yang diautentikasi atau tidak. Misalnya, aplikasi blog sering kali dapat membaca posting atau meninggalkan komentar anonim tanpa masuk. Selain itu, aplikasi yang mengharuskan pengguna untuk masuk harus menyediakan kemampuan masuk dan pemulihan akun untuk pengguna yang tidak diautentikasi.
Berdasarkan pengalaman kami, keputusan tentang fitur yang memerlukan persetujuan sering kali gagal atau dikaburkan oleh tim pengembangan. Ini sering terjadi ketika tidak ada mekanisme yang konsisten untuk memaksa beberapa fitur untuk mengautentikasi dan yang lainnya tidak. Setiap pengembang dalam tim harus membuat keputusan sendiri tentang cara menerapkan otentikasi.
Dalam hal manajemen fitur, fitur lama atau debug sering kali dapat menjadi sarana penyusupan bagi penyerang. Misalnya, fitur lama atau sementara yang dibuat di luar autentikasi dan dapat diakses oleh semua orang, bahkan melalui URL yang kompleks. Penyerang pandai menemukan hal-hal seperti itu!
Penting juga untuk mengetahui hal-hal lain yang berkomunikasi dengan aplikasi Anda. Bahkan dengan mekanisme otentikasi yang baik yang diterapkan secara konsisten, Anda dapat dengan mudah kecewa dengan bagian lain dari tumpukan, seperti repositori kode sumber dan cadangan. Komponen yang berisi kunci kerajaan harus dilindungi dengan setidaknya otentikasi yang sama yang digunakan dalam aplikasi.
Apa yang bisa kau lakukan?
Penting untuk memasukkan pemikiran keamanan ke dalam proses pengembangan dan konfigurasi aplikasi. Tapi apa ini benar-benar berarti?
Ada lima hal penting yang dapat Anda lakukan untuk melindungi aplikasi Anda dari jenis serangan ini.
- Pastikan kata sandi disimpan dalam format yang disandikan (disarankan algoritma hash bcrypt, scrypt, atau Argon2)
- Tingkatkan penggunaan kata sandi di seluruh organisasi Anda: Untuk informasi selengkapnya, lihat entri blog kata sandi.
- Pastikan semua titik login dilindungi dari serangan brute force dengan membatasi jumlah upaya login yang gagal dalam waktu singkat.
- Gunakan otentikasi multi-faktor! Di sinilah pengguna mungkin diminta untuk memberikan beberapa identifikasi untuk masuk. Misalnya, kode untuk aplikasi kata sandi satu kali berbasis waktu seperti nama pengguna, kata sandi, Google Authenticator, dll.
- Hindari merancang sertifikasi Anda sendiri. Ada perpustakaan yang banyak digunakan dan layanan pihak ketiga yang mungkin menawarkan otentikasi yang lebih kuat daripada yang dikembangkan sendiri.
Apakah Anda sudah melakukannya? Kemudian pertimbangkan hal berikut:
- Pastikan Anda memahami profil pengguna aplikasi Anda dan membuat keputusan yang konsisten tentang profil mana yang dapat mengakses profil mana.
- Hanya satu titik login yang diberikan kepada pengguna. Semakin banyak titik masuk yang dimiliki aplikasi Anda, semakin sulit untuk mengamankannya.
- Pastikan semua data Anda tersimpan dengan aman. Ini memastikan bahwa hanya pengguna yang secara eksplisit berwenang untuk mengakses data yang dapat mengaksesnya.
- Saat menetapkan hak istimewa pengguna, pastikan bahwa hak istimewa tingkat administrator hanya diberikan kepada mereka yang secara eksplisit membutuhkannya.
- Gunakan API Have I been Pwned (HIBP) untuk mengidentifikasi dan menolak kombinasi nama pengguna dan kata sandi yang diajukan yang diidentifikasi dalam pelanggaran data dan kata sandi yang biasanya terdeteksi dalam pelanggaran tersebut.