Definisi dan Mekanisme IDOR
Insecure Direct Object Reference (IDOR) adalah jenis kerentanan akses kontrol yang terjadi ketika aplikasi mengekspos referensi langsung ke objek internal (seperti database key atau nama file) tanpa validasi otorisasi yang memadai. Penyerang dapat memanipulasi parameter ini untuk mengakses data milik pengguna lain.
Metodologi Pengujian IDOR
Pengujian IDOR memerlukan dua akun pengguna dengan tingkat hak akses yang sama namun data yang berbeda. Berikut adalah langkah-langkah teknis pengujian:
- Identifikasi parameter yang merujuk pada objek (contoh:
user_id=123,invoice_id=456, ataufile=report_01.pdf). - Login dengan Akun A dan catat nilai parameter objek milik Akun A.
- Login dengan Akun B dan ganti nilai parameter tersebut dengan nilai milik Akun A.
- Amati apakah server mengembalikan data milik Akun A ke Akun B. Jika berhasil, kerentanan IDOR terkonfirmasi.
| Komponen | Deskripsi Teknis |
|---|---|
| Parameter Target | ID, UUID, Filename, Path |
| Metode HTTP | GET, POST, PUT, DELETE |
| Kondisi Uji | Dua akun (User A & User B) |
| Indikator Sukses | HTTP 200 OK (Data User A terlihat di User B) |
Contoh Skenario Eksploitasi
Misalkan sebuah aplikasi memanggil data profil melalui URL: https://example.com/api/v1/profile?id=1001. Jika penyerang mengubah id=1001 menjadi id=1002 dan sistem tetap menampilkan data tanpa memeriksa apakah sesi pengguna saat ini memiliki hak akses ke id=1002, maka aplikasi tersebut rentan.
Strategi Mitigasi
- Implementasi Access Control: Selalu verifikasi kepemilikan objek di sisi server sebelum memberikan akses.
- Gunakan Indirect Reference: Gunakan token acak (seperti UUID) yang dipetakan ke database ID asli, bukan menggunakan ID database yang berurutan.
- Pemeriksaan Sesi: Pastikan setiap permintaan data divalidasi terhadap ID pengguna yang tersimpan dalam sesi (session object).
Pengujian harus dilakukan di lingkungan staging atau development yang terisolasi untuk menghindari kebocoran data pengguna asli.