Bagaimana Mencari Bug IDOR ( Insecure Direct Object Reference )

Apa itu otorisasi dalam aplikasi web / seluler?

Manajemen sesi aplikasi web / seluler sangat penting bagi pengguna akhir. Manajemen sesi terdiri dari dua bagian penting, otentikasi dan otorisasi. Bagian otentikasi adalah jawaban dari pertanyaan “SIAPA SAYA?” Dan bagian otorisasi adalah jawaban dari pertanyaan “APA YANG BISA SAYA LAKUKAN?”.


Jika kami menjelaskan dengan pendekatan paling sederhana, kami mengamati tahapan otorisasi pada hak file sistem operasi Linux yang ditentukan sebagai tulis, baca, dan eksekusi. Jika pengguna ingin menulis file, bahwa pengguna harus diberi otoritas "w". Jika tidak digunakan dengan benar, ada beberapa pelanggaran privasi.

Apa itu Vulnerability IDOR?

Mungkin ada banyak variabel dalam aplikasi seperti "id", "pid", "uid". Meskipun nilai-nilai ini sering dilihat sebagai parameter HTTP, mereka dapat ditemukan di header dan cookie. Penyerang dapat mengakses, mengedit, atau menghapus objek pengguna lain dengan mengubah nilainya. Kerentanan ini disebut IDOR.

Pertama, perlu memahami aliran aplikasi yang dikembangkan oleh pengembang perangkat lunak. Semua fungsi modul dan fungsi sub-modulnya harus dipahami ketika pengguna yang masuk ke aplikasi web / seluler. Penting juga untuk diingat bahwa kerentanan ini sama parahnya dengan XSS, CSRF dalam pengujian keamanan dan sebagai jenis kerentanan yang tidak mudah ditemukan (pengujian otomatis atau pengujian manual).


Kerentanan IDOR diilustrasikan dalam gambar berikut antara pengguna dan server.

Tes Vulnerability IDOR yang efektif & cepat

Anda dapat menggunakan tab rahasia browser untuk dengan cepat menguji kerentanan IDOR. Jadi, saat Anda menggunakan tab reguler sebagai pengguna biasa, Anda bisa menggunakan tab rahasia sebagai penyerang. Ini akan memastikan bahwa Anda tidak keluar.

Anda dapat menggunakan tab Riwayat HTTP Burp Suite untuk memeriksa semua permintaan. Fitur HTTP History yang menunjukkan semua lalu lintas antara perangkat (browser, ponsel, tablet) dan server aplikasi. Anda juga dapat menggunakan fitur ruang lingkup Burp Suite untuk pengujian cepat. Karena fitur lingkup dapat berguna untuk membuat daftar target dan fitur lingkup memungkinkan hanya menampilkan data yang relevan untuk cakupan pengujian Anda.

Sebagai contoh; perusahaan "Bugcrowd" yang kami uji dan cakupannya hanya diberikan sebagai "bugcrowd.com" di halaman lingkup. Dalam hal ini, Anda dapat menambahkan cakupan yang relevan dengan mengklik kanan pada permintaan.

Anda dapat mengedit nilai lingkup tambahan ini sesuai dengan cakupan yang diberikan sebagai berikut

Terakhir, Anda harus melakukan pemfilteran berikut di tab Riwayat HTTP dengan memilih "Tampilkan hanya item dalam-lingkup"

Ini akan membantu Anda untuk memahami peran seperti hanya baca, normal, super dll dalam aplikasi dengan lebih baik.

Capture all requests!

Saat pengujian kerentanan IDOR, pada dasarnya, Anda harus melakukan semua permintaan yang harus dibuat oleh aplikasi web / seluler. Karena jika Anda mengubah sesuatu di aplikasi, dapat membuat permintaan lain menggunakan kasing ini. Jika Anda memiliki semua permintaan API dari aplikasi seperti file WSDL, halaman Swagger dll. Dan itu berfungsi secara teratur, Anda beruntung! Anda dapat menggunakan ini dan itu akan memberi Anda kenyamanan untuk pengujian IDOR.

Contoh ditemukan dalam program pribadi. Kartu kredit ditambahkan ketika melakukan pembelian di aplikasi seluler. Setelah permintaan diuji, dapat dipikirkan bahwa tidak ada kerentanan. Tetapi ketika pembelian kedua dilakukan, layar pemilihan kartu kredit terlihat dan kerentanan IDOR saat ini. Saat memilih kartu kredit di sini, aplikasi akan mengirimkan id kartu kredit ke server dalam permintaan dan permintaan ini memang menyediakan untuk mengakses data kartu kredit pengguna lain yang mengubah id kartu kredit.

Dalam program pribadi lainnya, aplikasi web menyertakan sistem pesan dalam aplikasi. Pengguna dapat mengirim pesan ke pengguna lain dan menambahkan pengguna lain ke pesan sendiri. Ketika pengguna mencoba mengakses salah satu pesannya sendiri, permintaan pergi ke “/ messages / 5955” dan id pesan milik sendiri sepertinya “5955”. Demikian juga, ketika mencoba mengakses pesan pengguna lain dengan membuat permintaan ke "/ messages / 5955", pesan itu tidak diakses. Ketika pengguna ingin menambahkan pengguna lain ke pesannya sendiri, muncul permintaan seperti di bawah ini.

POST / pesan / 5955 / undang HTTP / 1.1Host: example.comUser-Agent: Mozilla / 5.0 (Macintosh; Intel Mac OS X 10.12; rv: 52.0) Gecko / 20100101 Firefox / 52.0Menerima: * / * X-Diminta-Dengan : XMLHttpRequestCookie: my_cookiesConnection: closeuser = testaccount2

Dan ketika permintaan ini diperiksa, pengguna dapat menambahkan dirinya ke pesan pengguna lain dan mengakses semua pesan.


Selain itu, peran dalam aplikasi harus dipahami dengan baik untuk mengidentifikasi kerentanan IDOR. Jika Anda tahu apa yang harus dilakukan atau tidak dilakukan oleh suatu peran, itu akan sangat berguna selama fase deteksi kelemahan. Jadi pertama-tama, Anda harus memahami aplikasi ini dengan dalam!

Bagaimana cara menemukan titik injeksi?

Seperti sebelumnya katakan, Anda dapat menemukan banyak permintaan untuk pengujian kerentanan IDOR menggunakan semua fitur aplikasi. Ketika titik akhir API tidak disediakan dalam tes kerentanan IDOR, kode sumber .html atau file .js berguna. File-file ini termasuk hal-hal menarik dan permintaan ajax biasanya. Pengujian kerentanan IDOR dapat dilakukan menggunakan permintaan yang disajikan dalam file-file ini. Ini bisa berupa permintaan yang dibuat sebelumnya oleh aplikasi, dan kemungkinan permintaan di masa depan.

Jika Anda beruntung, Anda hanya dapat melihat permintaan yang diotorisasi, yang harus dilihat oleh pengguna admin dalam file javascript. Karena itu, kode sumber dan terutama file javascript harus dianalisis dengan baik.

Selain itu, Anda dapat mencari versi lama aplikasi web di "archive.org" dan Anda dapat menemukan permintaan yang berguna dalam file javascript lama atau Anda dapat mencari permintaan di mesin pencari menggunakan dorks.

Dalam beberapa kasus, nilai id tidak unik seperti 1, 2, 3, 100, 1000 dll, nilai id ini dapat dikodekan atau nilai hash. Jika Anda menghadapi nilai yang disandikan, Anda dapat menguji kerentanan IDOR dengan mendekode nilai yang disandikan. Jika Anda menghadapi nilai hash, Anda harus menguji apakah nilai hash adalah nilai yang dapat diakses atau diprediksi. Dalam kasus lain, Anda dapat mengakses nilai hash di header "Referrer", sehingga skenario ini dapat direplikasi.

Misalnya, Anda tidak dapat mengakses objek pengguna lain tetapi Anda dapat menemukan nilai id hash objek dalam kode sumber halaman objek, Anda dapat menemukan id hash objek ke dalam pesan dalam aplikasi dari pengguna korban (ini akan mengurangi dampaknya bug). Jadi, Anda dapat membuat 2 akun uji sebagai X dan Y, lalu mencoba nilai id hash X dalam permintaan Y di Riwayat Bersendawa.


Jika kami akan menyentuh topik lain, beberapa permintaan aplikasi mungkin membuat Anda takut. Misalnya, permintaan SmartSheet yang berisi lebih dari satu parameter tampaknya terlalu rumit.

Jika Anda ingin menemukan titik injeksi dalam permintaan ini, Anda dapat menggunakan alat perbandingan Burp Suite. Anda harus mengklik kanan pada permintaan dan memilih opsi "Kirim ke Pembanding". Kemudian Anda dapat membuat permintaan yang sama untuk menggunakan objek lain dan mengirim ke pembanding.

Ketika Anda mengunjungi alat pembanding dan mengklik tombol "Kata", Anda akan disajikan dengan jendela tempat titik-titik perubahan.

Anda dapat menggunakan metode yang sama untuk respons HTTP dan Anda dapat memeriksa perbedaannya.

Interesting cases for IDOR bugs

Manipulate the create requests

Beberapa aplikasi membuat id di sisi klien dan kemudian mengirim permintaan buat in ke server. Nilai id ini bisa berupa angka seperti "-1", "0" atau apa pun. Nilai id yang ada berubah dengan id objek yang dibuat sebelumnya. Jadi Anda dapat menghapus / mengedit objek pengguna lain menggunakan kerentanan IDOR.

Jika Anda tidak melihat parameter seperti "id", "user_id", "value", "pid", "post_id" saat membuat objek, Anda harus menambahkannya dan mengujinya sendiri. Anda dapat menemukan nama kunci parameter dengan menghapus atau mengedit objek apa pun di aplikasi.

Blind IDOR

Dalam kasus lain, Anda dapat menemukan kerentanan IDOR tetapi Anda mungkin tidak menyadarinya. Misalnya, jika Anda mengubah informasi objek di aplikasi, Anda akan mendapatkan email yang menyertakan informasi objek. Jadi, jika Anda mencoba mengubah informasi objek pengguna lain, Anda tidak dapat mengakses apa pun dalam respons HTTP tetapi Anda dapat mengakses informasi objek dengan email. Anda bisa menyebutnya "Blind IDOR".

Combine them!

Dampak bug IDOR dapat diubah dan kami akan menyentuhnya. Dalam beberapa kasus, kerentanan IDOR dapat membantu Anda dengan memicu kerentanan lain yang tidak dapat dieksploitasi. Jika Anda menemukan kerentanan IDOR yang tidak penting seperti mengedit pengguna yang bukan publik & nama file tidak penting dan Anda ingin meningkatkan dampak bug Anda, Anda dapat menggunakan bug self-XSS. Kerentanan XSS diri yang Anda temukan saat pengujian aplikasi web umumnya di luar jangkauan dan tidak dihargai. Namun, Anda dapat menggabungkan kerentanan XSS diri dengan kerentanan IDOR lain dan Anda dapat mengirimkan laporan sebagai “IDOR + Stored XSS”. Dengan cara ini Anda dapat mencapai kerentanan tingkat P2.

Critical IDORs

Kerentanan IDOR memungkinkan kita mengakses akun pada suatu waktu, daripada mengedit atau menghapusnya. Bug kritis ini muncul di bidang seperti pengaturan ulang kata sandi, perubahan kata sandi, pemulihan akun. Jadi pertama-tama, Anda harus memeriksa tautan di email Anda dan parameter di dalamnya. Kemudian, Anda dapat menangkap permintaan pengaturan ulang kata sandi dan memeriksa parameter dengan alat proxy apa pun. Kami telah melihat berkali-kali nilai "id pengguna" dalam permintaan ini dan kami dapat dengan mudah mengambil alih ke akun pengguna lain.

Pada saat yang sama, itu adalah hal penting yang mengambil alih akun dengan nilai header yang dikirim dalam permintaan. Terlihat bahwa beberapa nilai header seperti "X-User-ID", "X-UID" dari lingkungan pengujian dan debug diubah. Sehingga pengguna dapat bertindak seperti pengguna mana pun dan berhasil mengambil alih akun.

HPP Bug

Dalam kasus yang jarang terjadi, Anda dapat menguji kerentanan HPP (HTTP Parameter Pollution) untuk pengujian IDOR dengan menambahkan parameter yang sama sekali lagi dalam permintaan Anda. Contoh dari ini: https://www.youtube.com/watch?v=kIVefiDrWUw

Create valid request

Anda harus yakin bahwa permintaan kirim ke server sudah benar. Jika Anda mencoba mengirim permintaan pengguna dengan pengguna lain, Anda harus yakin bahwa nilai "CSRF-Token" permintaan ini valid. Jadi Anda harus memasukkan "CSRF-Token" pengguna lain ke dalam permintaan. Kalau tidak, Anda akan mendapatkan kesalahan karena nilai token tidak cocok. Ini bisa membuat Anda menyesatkan.

Demikian juga, jika permintaan Anda yang diuji adalah XHR (Permintaan HTTP XML), Anda harus memeriksa validasi parameter header "Tipe Konten" dalam permintaan Anda. Selain itu, permintaan aplikasi mungkin memiliki tajuk khusus seperti "W-User-Id", "X-User-Id", "User-Token" dll. Jika Anda ingin melakukan tes yang benar dan sempurna, Anda harus mengirim semua tajuk yang digunakan oleh aplikasi sudah benar.

Useful tools

Seperti yang kami sebutkan sebelumnya, Anda dapat menggunakan fitur Burp Suite. Anda juga dapat menggunakan plugin Burp Suite untuk pengujian kerentanan IDOR, seperti "Authz", "AuthMatrix" dan "Authorize".

Plugin Authz menyediakan untuk melihat respons permintaan untuk pengguna lain. Jadi, Anda dapat mengirim permintaan pengguna X ke Authz dan mencoba mengakses responsnya sebagai pengguna Y. Anda juga dapat menambahkan tajuk khusus untuk kerentanan IDOR pengujian seperti "X-CSRF-Token". Anda bisa mendapatkannya dari BApp Store atau di alamat ini.

Plugin AuthMatrix memungkinkan Anda untuk melakukan pemeriksaan otorisasi dengan mendaftarkan nilai cookie atau nilai header untuk peran dalam aplikasi. Anda bisa mendapatkannya dari BApp Store dan jika Anda ingin informasi lebih lanjut untuk plugin yang bagus ini, buka di sini.

Jika Anda memiliki permintaan API, Anda dapat menggunakan plugin Wsdler untuk Burp Suite, SoapUI, Postman, dll. Anda dapat mencoba semua DAPATKAN, POST, PUT, HAPUS, permintaan PATCH dan sukses dan uji API cepat menggunakan alat.

Impact of IDOR vulnerabilities

Kerentanan IDOR nampak sebagai “VARI tergantung pada dampak” di Bugcrowd VRT karena pengaruhnya sangat bergantung pada bug yang Anda kirim.

Tetapi kami telah membuat daftar tentang dampak kerentanan IDOR berdasarkan pengalaman kami sebagai berikut.

P1 - Pengambilalihan akun, Akses data yang sangat penting (seperti kartu kredit)

P2 - Mengubah / menghapus data publik pengguna lain, Mengakses data penting pribadi / publik (seperti tiket, faktur, informasi pembayaran)

P3 - Akses / hapus / ubah data pribadi (info pribadi terbatas: nama, alamat, dll.)

P4 - Akses semua data yang tidak penting

Dampak kerentanan IDOR tergantung pada kebijaksanaan manajer program.

How to prevent IDOR vulnerabilities?

Pertama, Anda harus mengontrol semua permintaan normal, ajax, dan API saat membuat aplikasi. Misalnya, dapatkah pengguna hanya baca menulis sesuatu di aplikasi? Atau bisakah pengguna non-admin mengakses dan membuat token API yang hanya dibuat oleh pengguna admin? Jadi, untuk menguji semua kerentanan IDOR, Anda harus berpikir seperti seorang peretas.

Anda dapat memberikan izin pada aplikasi Anda untuk semua titik akhir. Jika titik akhir "privatesection" Anda mencakup permintaan API seperti "/ api / privatesection / admin", "/ api / privatesection / console", "/ api / privatesection / token", Anda dapat memblokir titik akhir untuk pengguna non-admin.

Selain itu, untuk membuat pekerjaan penyerang lebih sulit dan bahkan kadang-kadang bahkan untuk mencegahnya, Anda dapat menggunakan fungsi hash dan menggunakan nilai hash alih-alih angka atau string normal.