Post cover image

September 11, 2026

Dari Activity Log ke Pelanggaran Privasi: Mengeksploitasi Broken Object Level Authorization

Riwayat aktivitas akun merupakan komponen kritis dalam arsitektur keamanan aplikasi modern. Fitur ini dirancang untuk memberikan…

By 0xHunter

3 min read

Riwayat aktivitas akun merupakan komponen kritis dalam arsitektur keamanan aplikasi modern. Fitur ini dirancang untuk memberikan visibilitas kepada pengguna terkait tindakan apa saja yang terjadi di dalam akun mereka. Informasi yang tersimpan di dalamnya sangat sensitif, mencakup alamat IP, jenis perangkat, user agent, timestamp, hingga detail perubahan pengaturan.

Kerentanan pada endpoint ini sering kali terlewat dari pengujian dibandingkan dengan endpoint profil pengguna atau pembayaran. Prediktabilitas identifier dan kompleksitas implementasi kontrol akses tingkat objek membuat endpoint riwayat aktivitas menjadi target yang sesuai untuk pengujian IDOR. Ketiadaan otorisasi sisi server yang memadai memungkinkan penyerang untuk membaca riwayat aktivitas milik pengguna lain secara sepihak.

Memahami Attack Surface

Implementasi pencatatan log bervariasi bergantung pada arsitektur sistem. Dari perspektif keamanan, kita umumnya berhadapan dengan fitur - fitur berikut:

  1. Login History: Mencatat waktu, IP, dan status keberhasilan login.
  2. Activity History: Mencatat modifikasi data seperti perubahan kata sandi atau email.
  3. Session History: Mengelola sesi aktif, sering terhubung dengan fitur remote logout.
  4. Audit Log: Umum ditemukan di aplikasi B2B/SaaS untuk merekam tindakan administratif dalam satu tenant atau organisasi.
  5. Security Events: Notifikasi terkait anomali akses.

Secara teknis, klien akan mengirimkan permintaan API ke server untuk menarik data ini. Permintaan tersebut biasanya menyisipkan pengenal identifier seperti ID pengguna atau ID log tertentu.

Metodologi Endpoint Discovery

Mencari endpoint yang memproses data riwayat butuh ketelitian. Berikut pendekatan yang biasa digunakan:

  1. Pemetaan Fitur: Eksekusi seluruh fungsi di halaman pengaturan dan keamanan. Jangan hanya melihat UI, perhatikan alur datanya.
  2. Intersepsi Proxy: Gunakan tools seperti Burp Suite atau OWASP ZAP untuk menangkap dan menahan permintaan API di balik layar.
  3. Analisis DevTools: Pantau tab Network di browserr untuk melihat struktur permintaan XHR/Fetch saat halaman riwayat dimuat.
  4. Analisis JavaScript: Cari endpoint tersembunyi di dalam berkas source map. Sering kali, API versi lama masih aktif dan kehilangan lapisan otorisasi modernnya.
  5. Identifikasi Identifier: Target utamanya adalah parameter yang merujuk langsung ke sebuah objek. Cari angka berurutan atau string yang polanya bisa diprediksi.

Validasi Kepemilikan Objek

Server tidak boleh memercayai input dari klien begitu saja. Saat menerima permintaan untuk mengakses sebuah objek, server wajib melakukan dua lapis validasi:

  1. Autentikasi: Memastikan pemohon memiliki sesi valid => memvalidasi token JWT atau session cookie.
  2. Otorisasi: Memastikan identitas yang sudah diautentikasi tersebut benar - benar memiliki hak eksplisit untuk membaca atau mengubah objek yang diminta.

Kerentanan IDOR terjadi saat server hanya mengeksekusi langkah pertama, lalu mengabaikan langkah kedua.

Analisis Perbandingan Respons

Pengujian IDOR membutuhkan minimal dua akun => Akun A dan Akun B. Kita membandingkan bagaimana server merespons saat identifier dimanipulasi.

| Indikator           | Saat Mengakses Data Sendiri | Indikasi Rentan                 | Indikasi Aman                    |
| ------------------- | --------------------------- | ------------------------------- | -------------------------------- |
|   HTTP Status       |   200 OK                    |  200 OK                         |   401,  403 , atau 404           |
|   Response Body     |   Data aktivitas lengkap    |  Data aktivitas milik target    |   Kosong, [], atau error generik |
|   Response Length   |   Signifikan                |  Signifikan                     |   Sangat kecil                   |

Hati2 pada false positive. Jika Anda mengubah ID lalu server merespons dengan 200 OK tetapi datanya kosong atau memunculkan halaman publik yang memang tidak diproteksi, itu bukan IDOR.

Analisis Dampak Bisnis

Penilaian dampak harus objektif dan didasarkan pada jenis data yang terekspos.

  1. Dampak High: Endpoint membocorkan token sesi aktif atau reset token. Informasi ini bisa langsung dieksploitasi untuk mengambil alih akun.
  2. Dampak Medium: Endpoint membocorkan alamat IP presisi, lokasi geografis, dan metadata perangkat. Dampak utamanya adalah pelanggaran privasi dan memfasilitasi serangan social engineering yang sangat tertarget.
  3. Dampak Low: Hanya membocorkan timestamp dan log aksi generik misalnya User logged in tanpa metadata spesifik atau pengenal unik pengguna.

NOTED: Contoh di bawah ini murni ilustrasi teknis. Endpoint, identitas, dan struktur respons tidak merujuk pada target atau aplikasi nyata mana pun.

Asumsikan klien mengirimkan request untuk memuat riwayat perangkat.

Request Asli => Sesi milik user_A:

GET /api/v1/user/devices?user_id=8055 HTTP/1.1
Host: api.ilustrasi-sistem.local
Authorization: Bearer <token_user_A>

Response Asli:

HTTP/1.1 200 OK

{
 “user_id”: 8055,
 “last_ip”: “192.168.1.10”,
 “device_model”: “iPhone 13,3”
}

Penguji kemudian mengubah parameter user_id menjadi milik akun lain => 8056.

Request Termanipulasi => Sesi user_A, meminta data user_B:

GET /api/v1/user/devices?user_id=8056 HTTP/1.1
Host: api.ilustrasi-sistem.local
Authorization: Bearer <token_user_A>

Response Indikasi IDOR:

HTTP/1.1 200 OK

{
 “user_id”: 8056,
 “last_ip”: “10.0.0.5”,
 “device_model”: “Samsung SM-G998B”
}

Respons ini membuktikan server memvalidasi token user_A sebagai entitas sah, tetapi gagal memastikan apakah user_A berhak membaca data user_id 8056.

Proof of Concept

Dalam konteks pelaporan bug bounty atau pentest, laporan tidak butuh narasi panjang, melainkan bukti yang solid dan dapat direproduksi:

  1. Lampirkan raw HTTP Request dan Response asli => Akun A mengakses datanya sendiri.
  2. Lampirkan raw HTTP Request dan Response yang termanipulasi => Akun A sukses mengakses data Akun B.
  3. Buktikan bahwa temuan ini stabil. Pastikan kebocoran data bukan sekadar caching sementara atau race condition.
  4. Sorot data sensitif spesifik yang berhasil ditarik untuk menjustifikasi severity.

Rekomendasi Mitigasi

Menambal IDOR membutuhkan pendekatan struktural di sisi backend, bukan sekadar menyembunyikan parameter di antarmuka pengguna.

  1. Pindahkan Otorisasi ke Backend: Validasi kepemilikan objek wajib dilakukan pada tingkat controller sebelum query ke database dieksekusi.
  2. Abaikan Parameter Klien: Untuk data personal, hindari penggunaan parameter ID di URL. Ubah rancangan endpoint dari /api/activity?user_id=8055 menjadi /api/activity/me. Biarkan server yang mengekstrak identitas pengguna secara mandiri dari session cookie atau token JWT yang telah divalidasi.
  3. Gunakan UUID: Mengganti auto-increment ID dengan UUID v4 tidak memperbaiki logika otorisasi yang rusak, tetapi sangat efektif mematikan kemampuan penyerang untuk melakukan enumeration dan ekstraksi data secara massal.
  4. Pengujian Regresi: Integrasikan skenario akses lintas akun ke dalam unit test CI/CD untuk memastikan kontrol otorisasi tidak terhapus secara tidak sengaja pada deploy berikutnya.

Poin Penting

  1. Absennya validasi otorisasi pada endpoint riwayat aktivitas membuka celah ekstraksi jejak digital pengguna lain.
  2. Autentikasi dan Otorisasi adalah dua proses terpisah yang harus dieksekusi berurutan.
  3. Konfirmasi IDOR membutuhkan minimal dua identitas berbeda untuk memastikan batas izin benar2 dilanggar.
  4. Menghentikan memercayai referensi objek yang dikirim oleh klien dan beralih menggunakan referensi yang diekstrak langsung dari sesi backend.