POC Insecure Direct Object Reference pada sebuah endpoint

Saya kembali lagi akan membuat POC mengenai bagaimana saya menemukan sebuah kerentanan Insecure Direct Object Reference pada sebuah endpoint yang digunakan untuk mengambil daftar channel pengiriman OTP pada sebuah aplikasi.

Insecure Direct Object Reference


Langkah awal yang saya lakukan adalah melakukan reconnaissance terhadap fitur autentikasi pada aplikasi tersebut. Saat melakukan proses login dan verifikasi OTP, saya melakukan intercept request menggunakan Burp Suite untuk melihat komunikasi antara client dan server.

Dari hasil pengamatan tersebut saya menemukan sebuah endpoint yang dipanggil secara asynchronous untuk mengambil daftar metode pengiriman OTP.

GET /refresh_otp_channels_list?practitioner_id=4

Endpoint tersebut menggunakan parameter practitioner_id untuk menentukan data practitioner mana yang akan ditampilkan pada halaman pemilihan metode OTP.

Untuk memastikan bagaimana mekanisme endpoint tersebut bekerja, saya mencoba mengirimkan request secara manual menggunakan repeater dengan parameter yang sama seperti request asli dari aplikasi.

GET /refresh_otp_channels_list?practitioner_id=4 HTTP/2

Server merespon dengan status 200 OK dan mengembalikan data berupa daftar channel OTP yang dapat digunakan oleh practitioner tersebut. Data tersebut kemudian dirender langsung ke dalam halaman menggunakan JavaScript.

Pada respon yang diterima terlihat beberapa informasi seperti alamat email yang digunakan untuk menerima OTP serta beberapa alamat lokasi praktik.

k*************z@interop-m****te.ap***pt.org

k*************z@men.m***nte.fr

k*************z@me***in.oc.m***nte.fr

Selain itu juga terdapat beberapa alamat praktik yang ditampilkan pada respon.

CENTRE **** RAVAS - MALBOSC, 318 AV***E DE FES, 34000 MO***LIER

HOPITAL LAP***NIE CHU MONT***IER, 371 A*UE DU D***EN GAS*N GIR***D

Setelah memahami struktur request dan respon tersebut, saya kemudian mencoba melakukan pengujian sederhana dengan mengubah nilai parameter practitioner_id.

/refresh_otp_channels_list?practitioner_id=1

/refresh_otp_channels_list?practitioner_id=2

/refresh_otp_channels_list?practitioner_id=5

Hal yang menarik adalah server tetap memberikan respon yang valid meskipun nilai practitioner_id diubah ke ID lain.

Artinya aplikasi tidak melakukan validasi apakah pengguna yang sedang login benar-benar memiliki akses terhadap practitioner_id yang diminta.

Dengan kondisi tersebut seorang attacker berpotensi melakukan enumerasi terhadap ID practitioner yang ada pada sistem hanya dengan mengganti nilai parameter tersebut.

Setiap ID yang valid akan mengembalikan informasi terkait channel OTP yang tersedia beserta beberapa informasi tambahan seperti alamat email yang digunakan dan alamat lokasi praktik.

Kerentanan ini termasuk dalam kategori Insecure Direct Object Reference karena aplikasi mempercayai parameter yang dikirim oleh client tanpa melakukan verifikasi kepemilikan data pada sisi server.

Dalam skenario yang lebih lanjut, informasi ini dapat dimanfaatkan untuk melakukan serangan lain seperti user enumeration, social engineering, ataupun reconnaissance terhadap target tertentu.

Artikel ini dibuat untuk tujuan edukasi agar pengembang dapat memperbaiki mekanisme validasi akses pada endpoint sensitif, khususnya endpoint yang berhubungan dengan proses autentikasi seperti pengiriman OTP.

1 Komentar

Kritik dan Saran

Lebih baru Lebih lama

نموذج الاتصال