IDOR Parameter Manipulation: Definisi, Celah, & Cara Mencegah

Insecure Direct Object Reference (IDOR) Parameter Manipulation adalah jenis kerentanan keamanan web di mana aplikasi mengekspos referensi ke objek internal—seperti database record, file, atau kunci primer—langsung ke pengguna tanpa validasi kontrol akses yang memadai. Penyerang dapat memanipulasi parameter di URL, form body, atau header HTTP (misalnya mengubah ?user_id=101 menjadi ?user_id=102) untuk mengakses, memodifikasi, atau menghapus data milik pengguna lain secara ilegal.

Celah ini masuk dalam kategori Broken Access Control yang menempati peringkat teratas dalam daftar OWASP Top 10. IDOR sering kali terjadi karena pengembang mengandalkan kerahasiaan URL atau asumsi bahwa pengguna tidak akan mencoba menebak atau mengubah nilai parameter yang dikirimkan ke server.

Mekanisme Kerja dan Skenario Serangan IDOR

Secara mendasar, eksploitasi IDOR terjadi melalui manipulasi parameter input yang mereferensikan objek backend. Tanpa adanya verifikasi sesi (session validation) yang mengikat objek tersebut ke pemilik yang sah, sistem akan langsung mengeksekusi perintah kueri database.

Berikut adalah contoh implementasi kerentanan pada sisi server (PHP) yang rentan terhadap manipulasi parameter:

// Kode Rentan (Vulnerable Code)
$id_pesanan = $_GET['order_id'];
$query = "SELECT * FROM pesanan WHERE id = " . $id_pesanan;
$result = mysqli_query($conn, $query);
// Mengembalikan data pesanan tanpa memeriksa apakah pesanan milik user yang sedang login

Jika seorang pengguna dengan ID 45 mengakses halaman https://example.com/invoice.php?order_id=1005, lalu ia mengganti angka tersebut menjadi 1006, server akan tetap menampilkan faktur pesanan orang lain jika tidak ada pemeriksaan hak akses (authorization check).

Matriks Risiko dan Dampak Keamanan

Dampak dari eksploitasi IDOR bervariasi tergantung pada tingkat hak akses (privilege level) dari parameter yang dimanipulasi. Berikut adalah matriks risiko yang sering ditemukan dalam audit keamanan aplikasi web:

Langkah Teknis Mitigasi dan Pencegahan

Untuk menutup celah keamanan IDOR secara permanen, pengembang harus menerapkan kontrol akses berbasis peran (Role-Based Access Control / RBAC) dan validasi sisi server yang ketat pada setiap titik akhir (endpoint) API atau halaman web.

1. Implementasi Pengecekan Otorisasi Berbasis Sesi

Jangan pernah mempercayai input yang dikirimkan oleh klien. Selalu bandingkan objek yang diminta dengan identitas pengguna yang aktif di sesi saat ini (misalnya dari token JWT atau variabel session server).

// Kode Aman (Secure Implementation)
session_start();
$id_pengguna_aktif = $_SESSION['user_id'];
$id_pesanan = $_GET['order_id'];

// Pastikan pesanan benar-benar milik pengguna yang sedang aktif
$stmt = $pdo->prepare('SELECT * FROM pesanan WHERE id = ? AND user_id = ?');
$stmt->execute([$id_pesanan, $id_pengguna_aktif]);
$pesanan = $stmt->fetch();

if (!$pesanan) {
    http_response_code(403);
    exit('Akses ditolak atau data tidak ditemukan.');
}

2. Penggunaan Indirect References atau Mapping Map acak

Alih-alih menggunakan primary key database yang berurutan (auto-increment integer) seperti 1, 2, 3, gunakan pengenal yang tidak dapat ditebak, seperti UUID (Universally Unique Identifier) v4 atau hash acak yang terenkripsi.

3. Menerapkan Indirect Reference Map di Sisi Server

Gunakan peta referensi di mana klien hanya melihat ID acak sementara atau indeks sesi sementara yang dipetakan secara aman ke ID database yang sebenarnya di memori server.

Panduan Pengujian (Testing) untuk Developer

Sebelum merilis aplikasi ke lingkungan produksi (production), lakukan pengujian fungsional keamanan menggunakan langkah-langkah berikut:

• Gunakan alat intercept proxy seperti OWASP ZAP atau Burp Suite untuk menangkap lalu lintas HTTP.
• Catat semua permintaan yang menyertakan parameter objek (ID, path, nama file).
• Uji coba pertukaran akun dengan membuat dua akun berbeda (Akun A dan Akun B). Masuk sebagai Akun A, lalu coba akses sumber daya milik Akun B dengan mengganti parameter ID.
• Verifikasi apakah server mengembalikan respons kode 403 Forbidden, 401 Unauthorized, atau 404 Not Found alih-alih data valid milik pengguna lain.