"Writeup ini dipublikasikan atas seizin pihak yang bersangkutan. Seluruh temuan telah dilaporkan secara responsible disclosure dan telah diperbaiki sebelum writeup ini diterbitkan"

Beberapa waktu yang lalu ketika saya sedang booking untuk potong rambut di Hairnerds saya iseng iseng buat intercept request dari web untuk booking tersebut. Saya berpikir jika suatu web memiliki sebuah fitur pasti memiliki beberapa hal yang menarik untuk di tes.

Oleh karena itu saya langsung saja membuka burpsuite untuk meng-intercept request dari web tersebut. Dan berikut beberapa request yang ter-intercept dari web tersebut

Setelah saya lihat dan amati ternyata parameter pada masing masing endpoint mirip dengan query SQL. Setelah saya mencari tahu di internet ternyata parameter tersebut merupakan parameter rest api dari PostgREST, yaitu sebuah webserver yang otomatis mengubah database PostgreSQL langsung menjadi RESTful API. Nah karena saya melihat parameter id_customer dan valuenya integer biasa, saya langsung saja tes untuk IDOR.

Dapat terlihat saat value saya ubah ke eq.197752, response mengembalikan code 200 serta memberikan seluruh data id 197752. Dapat terlihat pada seluruh field data langsung berubah semua menjadi data id 197752. Hal ini membuktikan bahwa parameter id_customer pada endpoint booking ini memiliki kerentanan IDOR yang mengakibatkan seseorang dapat mengambil data milik orang lain.

Setelah IDOR tersebut terbukti saya kembali teringat bahwa parameter tersebut mirip sekali dengan query SQL, lalu saya mecoba apakah kita bisa mengambil seluruh data seperti dengan query SQL SELECT *.

Dan yap, terlihat data yang ter-retrieve pada response sebesar 29.500.346 bytes (29,5 MB). Hal tersebut membuktikan bahwa kita bisa mengambil seluruh data pada tabel booking hanya dengan mengubah parameter seperti dengan query SQL.

Setelah mencari tahu lebih lanjut, saya menemukan bahwa kondisi ini kemungkinan besar terjadi karena misconfigured Row-Level Security (RLS) pada PostgreSQL. PostgREST sendiri memang dapat mengekspos tabel PostgreSQL menjadi REST API, tetapi pembatasan akses data tetap harus dikontrol dari sisi database, salah satunya menggunakan RLS. Jika RLS tidak diaktifkan, tidak diterapkan pada role yang digunakan API, atau policy-nya terlalu permisif, maka user dapat membaca row yang seharusnya bukan miliknya.

Dalam kasus ini, endpoint booking tetap mengembalikan data ketika parameter id_customer diubah, bahkan memungkinkan pengambilan seluruh isi tabel menggunakan select=*, sehingga masalah utamanya bukan pada PostgREST-nya, melainkan pada konfigurasi kontrol akses di PostgreSQL yang tidak membatasi akses per user/customer.

Setelah mengonfirmasi adanya kerentanan tersebut, saya segera melaporkan temuan ini kepada pihak Hairnerds melalui mekanisme responsible disclosure. Laporan yang saya kirimkan berisi detail teknis kerentanan, langkah reproduksi, serta potensi dampak yang dapat ditimbulkan apabila tidak segera ditangani.

Demikian writeup ini saya sampaikan. Terima kasih telah meluangkan waktu untuk membaca. Semoga apa yang dibahas dalam writeup ini dapat menjadi pembelajaran dan memberikan manfaat bagi kita semua.

Special thanks kepada Mas Lizuardi beserta tim dari Hairnerds yang telah menanggapi laporan ini dengan baik serta memberikan apresiasi terhadap temuan yang saya laporkan.

Best regards, Fiqram Akmal