Di Bagian 3 sebelumnya, kita sudah membahas tentang SQL Injection (SQLi) - mulai dari pengertian dasarnya hingga cara mengeksploitasinya dalam konteks program bug bounty. Sekarang, di Bagian 4, kita akan melangkah lebih jauh dengan membahas salah satu kelemahan paling sering ditemukan dan berdampak besar pada aplikasi web maupun API, yaitu IDOR (Insecure Direct Object Reference).
Di bagian ini, kamu akan memahami apa itu IDOR, bagaimana mekanismenya bekerja, pola-pola umum yang sering muncul, cara mendeteksinya, hingga bagaimana para bug hunter biasanya memvalidasi dampak kerentanannya agar laporan mereka bernilai tinggi dan berpotensi mendapatkan reward dari program bug bounty.
Meski IDOR terlihat sederhana, celah ini sering luput dari perhatian karena banyak aplikasi tampak sudah “aman” hanya karena memiliki sistem login. Padahal, di balik itu, sering kali ada celah besar yang bisa dimanfaatkan jika logika otorisasi tidak diterapkan dengan benar.
Melalui tulisan ini, kamu akan diajak memahami cara mendeteksi celah IDOR, mengujinya dengan aman pada labs yang saya buat, serta mempelajari berbagai tips dan strategi praktis agar kamu bisa meningkatkan peluang menemukan IDOR di program bug bounty.
Apa Itu Bug IDOR?
Kalau kalian udah mulai nyemplung ke dunia bug bounty atau tertarik sama keamanan aplikasi, kamu mungkin pernah dengar istilah IDOR (Insecure Direct Object Reference). Kedengarannya teknis banget, ya? Tapi sebenarnya konsepnya nggak serumit itu, kok. Justru, ini salah satu bug yang paling sering ditemuin - dan bisa berdampak cukup parah kalau ada di tempat yang salah.
Singkatnya, IDOR adalah celah keamanan yang muncul ketika aplikasi ngasih akses langsung ke data atau objek (kayak file, akun, atau catatan tertentu) tanpa ngecek dulu apakah pengguna yang minta data itu memang punya hak buat ngelihatnya. Jadi, sistemnya cuma fokus ngasih data berdasarkan ID atau parameter yang dikirim, tanpa benar-benar ngecek siapa yang lagi pakai.
Dampak Bug IDOR
- Data pribadi bocor (nama, email, nomor telepon, dll).
- Data orang lain bisa dimanipulasi, kayak ubah profil atau hapus catatan.
- Reputasi aplikasi rusak, karena pengguna jadi nggak percaya lagi.
- Bahkan bisa berujung pada kerugian finansial kalau datanya sensitif.
Pertanyaan Umum Tentang IDOR
Apakah IDOR termasuk jenis Broken Access Control?
Ya, IDOR adalah salah satu bentuk dari Broken Access Control - kategori besar kerentanan yang melibatkan kontrol akses yang salah atau tidak lengkap.
Apakah semua aplikasi rentan terhadap IDOR?
Tidak semua, tapi aplikasi yang mengandalkan ID unik atau parameter langsung dalam URL atau API cenderung lebih berisiko jika tidak memiliki validasi izin pengguna.
Contoh Sederhana IDOR
Misalnya kamu login pada website untuk melihat profile, dan di halaman profile tersebut ada detail sensitif seperti email, no hp, alamat, dan lainnya. Dengan url seperti di bawah ini
https://website.com/profile?id=1Di parameter id ada sebuah angka 1 itu adalah ID Profile dari setiap pengguna, nah misalkan kamu iseng ganti id nya menjadi 2. Maka detail dari profile orang lain akan muncul.
https://website.com/profile?id=2
Pada labs IDOR ada beberapa list user, dan kalian login terlebih dahulu ke salah satu akun user dengan memasukan username dan password berikut
user1 : password123Setelah kalian berhasil Login maka kalian klik Profile Saya di halaman tersebut halaman akan menampilkan sebuah detail dari setiap profile user yang telah login, dengan detail user seperti, Nama, Email, No HP, dan lainnya.
Pada halaman profile tersebut, terlihat URL yang memiliki parameter id . Angka 1 pada parameter tersebut menunjukkan User ID dari pengguna.
https://labs.parkerzanta.net/bug/idor/profile.php?id=1Parameter id digunakan untuk menentukan data profil pengguna yang akan ditampilkan. Nilai 1 pada parameter tersebut merepresentasikan User ID milik pengguna yang sedang login, yaitu profile dari Asep Asmoting JR.
Masalah muncul ketika aplikasi sepenuhnya mempercayai nilai id yang dikirimkan melalui URL, tanpa melakukan validasi apakah User ID tersebut memang milik pengguna yang sedang login.
Ketika nilai parameter id diubah secara manual, misalnya:
https://labs.parkerzanta.net/bug/idor/profile.php?id=2
Maka labs tetap menampilkan data profil pengguna lain, yaitu prodile dari Ricardo Ucup. Maka dapat disimpulkan bahwa aplikasi tersebut rentan terhadap IDOR (Insecure Direct Object Reference). Pada labs ini, pengguna diwajibkan login untuk melihat detail profile masing-masing setiap user. Setelah berhasil login, pengguna akan diarahkan ke halaman profile
Dalam kondisi ini:
- Tidak ada pengecekan kepemilikan data (ownership)
- Tidak ada validasi otorisasi di sisi backend
- Akses data hanya bergantung pada parameter yang dikirimkan client
Dalam kasus lain, kerentanan IDOR tidak hanya terbatas pada fitur melihat profile, tetapi juga sering ditemukan pada fitur edit profile, melihat detail transaksi, dan masih banyak lagi. Ini hanya labs sederhana IDOR untuk melihat profile pengguna lain.
Pada banyak aplikasi web, melihat profil pengguna lain memang merupakan fitur yang valid, bukan sebuah bug. Selama data yang ditampilkan adalah data publik, maka kondisi ini bukan merupakan kerentanan IDOR.
Biasanya fitur ini digunakan untuk:
- Melihat profil publik pengguna lain
- Sistem forum, marketplace, atau komunitas
- Halaman author, seller, atau member
Penutup
Pada Belajar Bug Bounty Bagian 4: Mengenal dan Mengeksploitasi Bug IDOR (Insecure Direct Object Reference), kita telah membahas bagaimana IDOR dapat muncul bahkan pada fitur yang terlihat sederhana, seperti halaman profil pengguna.
Dalam lab ini, desain awal aplikasi sebenarnya hanya memperbolehkan pengguna melihat profil miliknya sendiri setelah login. Halaman profil menampilkan data sensitif seperti email, nomor HP, dan alamat, yang memang seharusnya hanya dapat diakses oleh pemilik akun tersebut.
Namun, permasalahan muncul ketika aplikasi menggunakan parameter id sebagai referensi langsung ke data pengguna, tanpa memastikan bahwa nilai id tersebut selalu sesuai dengan user yang sedang login. Akibatnya, dengan memodifikasi parameter id, pengguna dapat melihat detail profil pengguna lain - sebuah kondisi yang jelas melanggar konsep otorisasi.
Kasus ini menunjukkan bahwa:
- Login saja tidak cukup untuk menjamin keamanan
- Setiap endpoint harus melakukan validasi kepemilikan data
- Data privat tidak boleh bergantung pada input dari client
Melalui lab ini, kita belajar bahwa IDOR bukan tentang ada atau tidaknya parameter ID, melainkan tentang bagaimana aplikasi mengontrol akses terhadap data di balik parameter tersebut.
Posting Komentar