Apa Itu IDOR? Kenali Celah Keamanan yang Bisa Membuka Data Pengguna Tanpa Izin
Memahami Insecure Direct Object Reference, bagaimana celah ini terjadi, dampaknya pada website dan API, serta cara mendeteksi dan mencegahnya.
AUTHORIZED
1002
CUMA GANTI ID, DATA ORANG LAIN BISA TERBUKA?
Identifier terlihat sederhana, tetapi masalah sebenarnya bukan pada angka tersebut. Pertanyaannya adalah: apakah server benar-benar memeriksa siapa yang berhak mengakses objek itu?
Apa Itu IDOR (Insecure Direct Object Reference)?
IDOR adalah celah keamanan ketika aplikasi menggunakan referensi langsung terhadap sebuah objek—misalnya ID pengguna, nomor pesanan, ID dokumen, atau ID perangkat—tetapi tidak memastikan bahwa pengguna yang sedang login memang memiliki hak untuk mengakses objek tersebut.
Dengan kata lain, aplikasi mungkin sudah berhasil mengenali siapa pengguna, tetapi gagal memeriksa objek apa yang boleh diakses pengguna tersebut.
Bagaimana IDOR Bisa Terjadi?
Secara umum, IDOR muncul ketika aplikasi menerima object reference dari client dan mempercayainya tanpa validasi otorisasi yang memadai di sisi server.
WHO ARE YOU?
Memastikan identitas pengguna, misalnya melalui login, session, token, atau mekanisme identitas lainnya.
WHAT CAN YOU ACCESS?
Menentukan objek, fungsi, dan data apa yang boleh diakses atau diubah oleh pengguna tersebut.
Jika authentication berhasil tetapi authorization terhadap objek tidak dilakukan dengan benar, pengguna yang valid dapat mencoba mengakses objek milik pengguna lain.
Contoh Sederhana Vulnerability IDOR
Bayangkan sebuah aplikasi memiliki endpoint untuk melihat detail pesanan:
GET /api/orders/1001
Pengguna kemudian mengubah identifier menjadi objek lain:
GET /api/orders/1002
Jika server mengembalikan detail pesanan 1002 padahal pengguna tersebut tidak memiliki hak akses terhadapnya, masalahnya bukan karena pengguna berhasil menebak angka. Masalah utamanya adalah server tidak melakukan validasi authorization terhadap objek tersebut.
Di Mana IDOR Biasanya Ditemukan?
IDOR tidak terbatas pada URL. Selama aplikasi menggunakan identifier untuk merujuk objek, terdapat kemungkinan authorization terhadap objek tersebut perlu diuji.
URL & Query
Contoh: /orders/1001, ?user_id=1001, atau parameter lain yang merujuk objek tertentu.
Endpoint & Body
Object reference dapat muncul pada path API, query, JSON body, atau identifier resource.
Device & Telemetry
Contoh: /api/device/1001 yang mengakses profil perangkat, telemetry, konfigurasi, atau fungsi tertentu.
Berbagai antarmuka dapat memiliki bentuk berbeda, tetapi prinsip keamanannya sama: authorization harus ditegakkan di sisi server.
Apa Dampak IDOR?
Dampak bergantung pada objek dan fungsi yang dapat diakses. Semakin sensitif objeknya, semakin besar konsekuensi yang mungkin terjadi.
Unauthorized Data Access
Data pengguna, transaksi, dokumen, profil, atau informasi sensitif dapat terbaca oleh pengguna yang tidak berhak.
Data Modification
Jika endpoint mendukung update, penyerang dapat mencoba mengubah objek milik pengguna lain.
Data Deletion
Objek yang dapat dihapus tanpa validasi kepemilikan dapat menyebabkan kehilangan atau gangguan data.
Privilege Escalation
Pada konteks tertentu, akses terhadap objek atau fungsi sensitif dapat berkembang menjadi eskalasi hak akses.
IDOR dan Broken Access Control
IDOR merupakan salah satu bentuk masalah access control. Dalam klasifikasi OWASP modern, isu semacam ini berada dalam ranah Broken Access Control. Pada API, istilah yang sangat berkaitan adalah Broken Object Level Authorization (BOLA).
Karena itu, pengujian IDOR sebaiknya tidak hanya bertanya “apakah ID bisa diganti?”, tetapi juga memeriksa apakah setiap operasi terhadap objek menerapkan aturan akses yang benar.
Bagaimana Cara Mendeteksi IDOR?
Pengujian dilakukan dengan memahami bagaimana aplikasi mereferensikan objek, lalu memvalidasi apakah server konsisten menerapkan authorization. Pengujian keamanan hanya boleh dilakukan pada sistem yang memang memiliki izin untuk diuji.
Identifikasi Object Reference
Cari identifier pada URL, parameter, request body, API endpoint, file reference, atau resource lainnya.
Gunakan Account atau Scope Berbeda
Bandingkan akses dari dua pengguna dengan kepemilikan atau privilege yang berbeda.
Uji Object-Level Authorization
Periksa apakah pengguna A dapat mengakses objek milik pengguna B atau objek di luar scope-nya.
Analisis Response
Perhatikan status code, isi response, perubahan data, dan perilaku aplikasi setelah request dilakukan.
Validasi Dampak
Tentukan apakah masalah hanya pada read atau juga memengaruhi create, update, delete, export, atau fungsi sensitif lainnya.
Apakah UUID Bisa Mencegah IDOR?
Mengganti angka berurutan dengan UUID dapat membuat identifier lebih sulit ditebak, tetapi UUID bukan pengganti authorization.
UUID ≠ Authorization
Identifier yang sulit ditebak tetap dapat diakses oleh pihak yang memperoleh identifier tersebut. Kontrol akses harus tetap diperiksa oleh server.
Bagaimana Cara Mencegah IDOR?
Pencegahan perlu berfokus pada authorization di server, bukan hanya membuat identifier sulit ditebak.
Server-Side Authorization
Validasi hak akses setiap kali resource sensitif diminta atau dimodifikasi.
Ownership Validation
Pastikan objek memang dimiliki atau berada dalam scope pengguna yang melakukan request.
Least Privilege
Berikan akses minimum yang dibutuhkan untuk setiap role dan fungsi.
Secure Object References
Identifier yang tidak mudah ditebak dapat menjadi defense-in-depth, tetapi bukan kontrol utama.
Logging & Monitoring
Catat pola akses abnormal dan aktivitas terhadap resource sensitif untuk membantu deteksi.
Security Testing
Masukkan authorization testing ke dalam pengujian aplikasi dan regression security testing.
Mengapa IDOR Perlu Diuji dalam Penetration Testing?
Kerentanan authorization sering tidak terlihat hanya dari tampilan aplikasi. Sebuah fitur dapat bekerja normal untuk pengguna yang sah, tetapi memiliki masalah ketika request dimanipulasi atau digunakan dari konteks akun yang berbeda.
Dalam penetration testing, pengujian dapat mencakup object ownership, horizontal access, privilege boundary, jenis operasi, sensitivitas data, serta endpoint API yang mungkin tidak terlihat dari antarmuka pengguna.
Apakah Aplikasi Anda Sudah Memeriksa Siapa yang Boleh Mengakses Apa?
Authorization yang kuat bukan sekadar memastikan pengguna berhasil login. Setiap akses terhadap objek dan fungsi sensitif perlu memiliki kontrol yang tepat.