Definisi Insecure Direct Object References (IDOR)
Insecure Direct Object References (IDOR) adalah salah satu kerentanan keamanan yang unik dan sering kali terabaikan dalam pengembangan aplikasi web. Sebelum kita membahas lebih lanjut mengenai cara mengatasi IDOR, mari kita mengenal terlebih dahulu definisi dari beberapa perusahaan keamanan siber terkemuka:
- OWASP (2001) OWASP mendefinisikan IDOR sebagai kerentanannya yang terjadi ketika penyerang dapat mengakses atau memodifikasi objek dengan memanipulasi pengidentifikasi yang digunakan dalam URL atau parameter aplikasi web.
- PortSwigger (2004) Menurut PortSwigger, IDOR adalah jenis kerentanannya kontrol akses yang muncul ketika aplikasi menggunakan input pengguna untuk mengakses objek secara langsung tanpa validasi yang memadai.
- Acunetix (2007) Acunetix menjelaskan IDOR sebagai masalah keamanan yang terjadi ketika pengembang menggunakan pengidentifikasi untuk mengakses objek internal secara langsung tanpa kontrol akses tambahan atau pemeriksaan otorisasi.
- Invicti (2009) Invicti mendefinisikan IDOR sebagai kerentanannya yang muncul ketika pengembang hanya menggunakan pengidentifikasi untuk mengarah ke elemen halaman yang seharusnya dilindungi oleh kontrol akses atau memerlukan otorisasi.
Dari semua definisi di atas, kita dapat menyimpulkan bahwa IDOR adalah jenis kerentanan keamanan yang terjadi ketika aplikasi memungkinkan pengguna untuk mengakses data atau objek yang seharusnya tidak dapat mereka akses, biasanya melalui manipulasi parameter dalam URL atau permintaan.
Mengenal Lebih Dekat IDOR
IDOR (Insecure Direct Object Reference) termasuk dalam kategori Broken Access Control, yang berarti kerentanannya muncul akibat kesalahan dalam pengimplementasian kontrol akses di aplikasi. Kerentanannya terjadi ketika aplikasi web tidak memverifikasi dengan tepat apakah pengguna yang mencoba mengakses objek tertentu memiliki izin yang sah. Tanpa pemeriksaan kontrol akses yang memadai, pengguna dapat mengakses data atau objek yang seharusnya tidak mereka miliki izin untuk mengakses.
Kerentanan ini sering kali ditemukan dalam aplikasi web yang tidak melakukan validasi atau kontrol akses yang tepat terhadap referensi objek yang diminta. IDOR memungkinkan penyerang untuk mengakses data pengguna lain, tanpa perlu meningkatkan hak akses mereka. Sebagai contoh, penyerang dapat mengubah ID dalam URL untuk melihat data pengguna lain yang berada pada tingkat yang sama, tanpa adanya pembatasan yang memadai.
IDOR lebih sering terjadi dalam serangan horizontal, di mana penyerang mencoba mengakses data pengguna lain yang berada pada tingkat yang sama tanpa adanya peningkatan hak akses.
IDOR memiliki sifat yang unik karena sulit dideteksi secara otomatis. Web Application Firewall (WAF) tidak dapat melindungi kerentanannya ini, dan berbagai tools scanning seperti Nuclei, X-Ray, dan alat lainnya belum dapat mendeteksi IDOR dengan efektif. Bahkan alat Vulnerability Assessment (VA) seperti Acunetix, Nessus, dan OWASP ZAP tidak dapat mendeteksi kerentanannya secara otomatis. Oleh karena itu, untuk mengidentifikasi kerentanannya, diperlukan pengujian manual yang lebih mendalam. Untuk memperbaikinya, tidak ada solusi instan menggunakan alat otomatis. Penting untuk melakukan audit manual terhadap sistem untuk memastikan bahwa kontrol akses diterapkan dengan benar.
Mengapa IDOR Masih Banyak Ditemukan?
Kerentanan IDOR masih banyak ditemukan karena sifatnya yang memerlukan pengujian manual. Aplikasi yang memiliki banyak fitur dan bagian sulit untuk diawasi satu per satu oleh perusahaan besar. Hal ini berbeda dengan kerentanannya yang lebih mudah dideteksi seperti SQL Injection, XSS, atau RCE, yang biasanya dapat dicegah dengan menggunakan WAF. Untuk serangan IDOR, penyerang harus memanipulasi referensi objek secara manual, yang sering kali tidak terdeteksi oleh perlindungan otomatis. Karena alasan inilah, banyak bug hunters di bug bounty programs yang berhasil menemukan kerentanannya ini, terutama pada aplikasi dengan tema SaaS (Software as a Service) atau platform kolaborasi, yang sering kali memiliki banyak akses dan referensi objek. Banyak bug hunters Indonesia yang mendapatkan bounty dari menemukan IDOR dalam aplikasi-aplikasi tersebut.
Contoh Serangan Sederhana IDOR
Untuk lebih memahami bagaimana Insecure Direct Object References (IDOR) dapat dimanfaatkan oleh penyerang, mari kita lihat contoh serangan sederhana IDOR yang dapat terjadi pada aplikasi web. Misalkan terdapat sebuah aplikasi web dengan URL berikut:
https://nusamandiri.ac.id/profil-mahasiswa?id=20
Pada URL ini, parameter id=20 merujuk pada profil pengguna dengan ID 20, yang merupakan attacker. Ketika halaman ini dibuka oleh attacker, profil yang muncul adalah:
Nama: attackers
Kelas : 12.8A.01
Tempat, Tanggal Lahir: Jakarta, 1 Januari 2000
Alamat: jl. Medan Merdeka No.45
Kemudian, ada URL lain dengan parameter berbeda:
https://nusamandiri.ac.id/profil-mahasiswa?id=21
Pada URL ini, parameter id=21 merujuk pada profil pengguna dengan ID 21, yang merupakan victim. Ketika halaman ini dibuka oleh victim, profil yang muncul adalah:
Nama: Vicim
Kelas : 12.7A.01
Tempat, Tanggal Lahir: Jakarta, 1 Desember 2000
Alamat: jl. Fatahillah No.47
Sekarang, misalkan attacker telah login dengan menggunakan ID 20 dan dapat melihat profilnya sendiri. Namun, jika attacker mengubah parameter URL dari id=20 menjadi id=21, seperti ini: https://nusamandiri.ac.id/profil?id=21 Maka yang muncul di tampilan profil adalah data milik victim, yaitu:
Nama: Vicim
Kelas : 12.7A.01
Tempat, Tanggal Lahir: Jakarta, 1 Desember 2000
Alamat: jl. Fatahillah No.47
Hal ini menunjukkan bahwa attacker telah berhasil mengakses data pribadi milik victim hanya dengan memanipulasi parameter id dalam URL, tanpa adanya kontrol akses yang memadai.
Severity IDOR
IDOR memiliki tingkat severity (tingkat keparahan) yang bervariasi, tergantung pada sejauh mana kerentanannya dapat dieksploitasi dan dampaknya terhadap aplikasi atau sistem. Berikut adalah gambaran umum tentang bagaimana severity IDOR bisa berbeda-beda:
- High - Critical Severity: Serangan IDOR yang mudah dieksploitasi, seperti dengan mengubah ID numerik yang berurutan dalam URL, dapat memberikan akses ke data sensitif seperti nomor rekening, detail transaksi, atau informasi pribadi lainnya. Penyerang dapat dengan mudah mengakses atau memodifikasi data yang seharusnya hanya dapat diakses oleh pemiliknya.
- Low - Medium Severity: Jika ID yang digunakan lebih kompleks (alfanumerik atau ter-hashing), serangan IDOR menjadi lebih sulit untuk dieksploitasi. Penyerang mungkin perlu menggunakan metode yang lebih rumit seperti brute-force untuk memperoleh akses, sehingga tingkat keparahannya lebih rendah.
Cara Mengatasi IDOR
Mengatasi IDOR memerlukan beberapa pendekatan yang tepat dan memadai. Salah satu cara untuk mengatasi kerentanannya ini adalah dengan menerapkan kontrol akses berbasis peran (Role-Based Access Control / RBAC) dan memastikan bahwa setiap pengguna hanya memiliki akses ke data atau objek yang sesuai dengan peran atau izin mereka.
Berikut adalah beberapa cara yang bisa digunakan untuk mengatasi IDOR:
- Gunakan Token Autentikasi yang Kuat
Salah satu cara untuk mencegah IDOR adalah dengan menggunakan token autentikasi yang aman dan mengikat token tersebut dengan sesi atau objek yang spesifik. Token ini bisa berupa JWT (JSON Web Token) atau OAuth. Setiap kali pengguna melakukan permintaan, token yang digunakan akan memastikan bahwa akses yang diberikan valid untuk objek atau data yang dimaksud. Dengan menggunakan token yang terikat pada objek atau sumber daya tertentu, aplikasi bisa lebih mudah memastikan apakah pengguna memiliki akses yang sah.
- Validasi Akses pada Setiap Permintaan
Setiap kali aplikasi memproses permintaan untuk mengakses objek atau data, pemeriksaan otorisasi harus dilakukan untuk memastikan bahwa pengguna yang membuat permintaan memiliki izin yang tepat. Ini bisa dilakukan dengan membandingkan ID objek dalam permintaan dengan hak akses yang terkait dengan akun pengguna tersebut.
- Menggunakan Model Kontrol Akses yang Ketat
Aplikasi harus mengimplementasikan model kontrol akses yang ketat dan melakukan verifikasi akses di setiap endpoint yang memerlukan otorisasi. Pastikan bahwa kontrol akses tidak hanya dilakukan pada level otentikasi, tetapi juga pada level aplikasi dan data.
- Audit dan Pemantauan Secara Berkala
Melakukan audit kode secara berkala dan memastikan bahwa kontrol akses diterapkan di seluruh aplikasi adalah langkah penting dalam mencegah IDOR. Selain itu, melakukan pemantauan terhadap akses data secara berkala untuk mendeteksi pola yang mencurigakan juga bisa membantu mendeteksi potensi kerentanan IDOR.
- Menghindari Penggunaan ID Berbasis Nomor
Salah satu cara untuk meningkatkan keamanan dan mengurangi potensi kerentanannya adalah dengan menghindari penggunaan ID berbasis angka atau nomor urut untuk mengakses data dalam URL. Misalnya, menggunakan ID seperti id=20, yang merupakan ID numerik berurutan, dapat memudahkan penyerang untuk melakukan serangan brute-force dan mengakses data pengguna lain dengan hanya menebak ID. Sebagai alternatif yang lebih aman, aplikasi sebaiknya menggunakan ID alfanumerik yang lebih kompleks dan acak (misalnya, id=4F5G8D1Z). Dengan menggunakan ID alfanumerik yang lebih sulit diprediksi atau ditebak, Anda secara signifikan mengurangi kemungkinan serangan brute-force. ID seperti ini membuat lebih sulit bagi penyerang untuk menebak ID pengguna lain dan mengakses data yang tidak seharusnya mereka akses.
Penulis
ALWI AL HADAD
06 April 2025
