IDOR atau Insecure Direct Object Reference merupakan salah satu kerentanan pada sisi authorization yang terjadi ketika aplikasi menggunakan ID atau identifier dari pengguna tanpa memastikan bahwa pengguna tersebut memiliki hak untuk mengakses data yang diminta. Kondisi ini dapat menyebabkan pengguna mengakses data milik pengguna atau perusahaan lain hanya dengan mengubah ID pada request.

Pada pengujian keamanan aplikasi LabKeu, pengujian difokuskan pada endpoint data keuangan perusahaan. Tujuannya adalah mengetahui apakah setiap perusahaan hanya dapat mengakses data miliknya sendiri atau apakah data perusahaan lain dapat diakses dengan mengubah ID pada URL.

❓ Apa Itu IDOR pada Aplikasi Web?

IDOR atau Insecure Direct Object Reference merupakan masalah keamanan ketika aplikasi menggunakan identifier seperti ID untuk menentukan data yang akan ditampilkan, tetapi tidak melakukan pemeriksaan authorization yang cukup.

Sederhananya, aplikasi dapat memiliki URL seperti /api/perusahaan/1/data-keuangan. Angka 1 digunakan untuk menentukan data perusahaan yang diminta. Masalah terjadi apabila pengguna dapat mengganti angka tersebut menjadi 2 dan server tetap memberikan data perusahaan lain tanpa mengecek apakah pengguna memang memiliki hak untuk mengaksesnya.

❓ Endpoint Apa yang Diuji?

Pengujian dilakukan pada endpoint API yang digunakan untuk mengambil data keuangan perusahaan.

Parameter <id> digunakan untuk menentukan perusahaan yang datanya akan dikembalikan oleh server. Pada kondisi yang seharusnya, pengguna hanya boleh mendapatkan data perusahaan yang sesuai dengan akun yang sedang digunakan.

❓ Bagaimana Kondisi Normalnya?

Pengujian pertama dilakukan menggunakan akun user_a yang berasal dari CV Sinar Abadi dengan perusahaan_id = 1.

Setelah login, endpoint data keuangan diakses menggunakan ID perusahaan yang sesuai dengan akun tersebut.

Request tersebut merupakan kondisi normal karena ID perusahaan yang diminta sesuai dengan perusahaan_id pada akun yang sedang digunakan.

❓ Apa yang Terjadi Ketika ID Perusahaan Diubah?

Setelah kondisi normal diketahui, pengujian dilanjutkan dengan mengubah ID perusahaan pada URL. Tujuannya adalah mengetahui apakah server melakukan pemeriksaan kepemilikan data atau hanya menggunakan ID yang dikirimkan oleh client.

ID pada URL diubah dari 1 menjadi 2, sementara akun yang digunakan masih merupakan user_a dari perusahaan dengan ID 1.

Setelah ID diubah, server tetap memberikan response 200 OK.

Response tersebut berisi data dengan perusahaan_id = 2, meskipun akun yang digunakan memiliki perusahaan_id = 1.

Padahal akun yang digunakan berasal dari perusahaan dengan perusahaan_id = 1. Artinya, akun tersebut dapat memperoleh data perusahaan lain hanya dengan mengubah ID pada endpoint.

❓ Apakah Masalah Ini Juga Terjadi pada Akun Lain?

Untuk memastikan hasil pengujian, pengujian juga dilakukan menggunakan akun perusahaan lain.

Dengan akun tersebut, endpoint kemudian diarahkan ke data perusahaan dengan ID 1.

Server kembali memberikan response 200 OK dan data dengan perusahaan_id = 1 dapat dikembalikan.

Pengujian dari dua arah menunjukkan bahwa masalah terjadi pada kontrol authorization endpoint, bukan hanya pada satu akun tertentu.

🚨 IDOR Berhasil Dibuktikan

Berdasarkan pengujian, server tidak membatasi data berdasarkan perusahaan yang dimiliki oleh pengguna. Pengguna yang sudah login dapat mengubah nilai :id pada endpoint dan memperoleh data perusahaan lain.

Temuan ini termasuk IDOR atau Insecure Direct Object Reference dan berkaitan dengan Broken Object Level Authorization.

❓ Mengapa IDOR Bisa Terjadi?

Masalah terjadi karena server mempercayai nilai ID yang dikirimkan melalui URL tanpa memastikan hubungan antara pengguna yang sedang login dengan resource yang diminta.

Dalam kasus LabKeu, pengguna dari perusahaan dengan ID 1 seharusnya tidak dapat meminta data perusahaan dengan ID 2. Server seharusnya membandingkan identitas perusahaan pada session dengan ID perusahaan yang diminta sebelum memberikan response.

🔍 Akar Masalah pada Aplikasi

Berdasarkan analisis terhadap aplikasi, masalah ditemukan pada bagian route data keuangan di routes/dashboard.js, khususnya pada bagian yang menangani endpoint data keuangan perusahaan.

Endpoint tersebut belum memastikan bahwa perusahaan yang diminta sesuai dengan perusahaan pada session pengguna.

Tanpa pemeriksaan tersebut, nilai :id dari URL dapat digunakan untuk meminta data perusahaan lain.

💥 Apa Dampak dari IDOR Ini?

Dampak yang berhasil dibuktikan dalam pengujian adalah kebocoran data keuangan lintas perusahaan. Akun yang seharusnya hanya berhubungan dengan satu perusahaan dapat membaca data perusahaan lain.

Dalam aplikasi yang menggunakan konsep multi-tenant, kondisi seperti ini dapat mengganggu pemisahan data antar perusahaan karena setiap pengguna seharusnya hanya memiliki akses terhadap resource yang menjadi haknya.

Temuan ini dikategorikan sebagai risiko HIGH dengan estimasi CVSS:

❓ Bagaimana Cara Memperbaiki IDOR?

Perbaikan utama harus dilakukan pada sisi server. Aplikasi tidak boleh hanya mempercayai ID yang dikirimkan oleh client. Setiap request harus diperiksa berdasarkan identitas pengguna dan hak aksesnya terhadap resource.

Dengan pengecekan tersebut, pengguna hanya dapat mengakses data perusahaan yang sesuai dengan hak aksesnya. Jika pengguna mencoba meminta data perusahaan lain, server harus menolak request tersebut.

❓ Apa yang Bisa Dipelajari dari Pengujian Ini?

Pengujian IDOR pada LabKeu menunjukkan bahwa login yang berhasil belum tentu berarti seluruh kontrol authorization sudah aman. Setelah pengguna berhasil login, server tetap harus memastikan bahwa setiap resource yang diminta memang boleh diakses oleh pengguna tersebut.

Dalam pengujian ini, proses dimulai dengan login menggunakan akun perusahaan, kemudian mengakses endpoint data keuangan dan mengubah ID perusahaan pada request. Ketika server tetap memberikan data perusahaan lain dengan status 200 OK, vulnerability IDOR dapat dikonfirmasi.

Pengujian dari dua arah juga menunjukkan bahwa masalah tidak hanya terjadi pada satu akun. Akun perusahaan dengan ID 1 dapat mencoba mengakses data perusahaan 2, dan akun perusahaan dengan ID 2 dapat mencoba mengakses data perusahaan 1.

✅ Kesimpulan

Pengujian terhadap aplikasi LabKeu berhasil mengonfirmasi adanya IDOR / Broken Object Level Authorization pada endpoint /api/perusahaan/<id>/data-keuangan.

Akun user_a dari CV Sinar Abadi dengan perusahaan_id = 1 dapat mengakses data perusahaan dengan ID 2. Pengujian sebaliknya menggunakan akun user_b juga menunjukkan bahwa data perusahaan dengan ID 1 dapat diakses oleh akun perusahaan dengan ID 2.

Hal tersebut terjadi karena server belum melakukan validasi kepemilikan resource berdasarkan session pengguna. Kondisi ini dapat menyebabkan kebocoran data keuangan lintas perusahaan dan menjadi masalah pada aplikasi yang menggunakan pemisahan data antar perusahaan.

Pengujian dilakukan hanya terhadap aplikasi LabKeu dalam lingkungan lab yang telah diotorisasi. Pengujian tidak ditujukan untuk sistem yang tidak memiliki izin pengujian.

✍️ Penulis: Noviana Putri Yuliani