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 belahan penting, otentikasi dan otorisasi. Bagian otentikasi yaitu tanggapan dari pertanyaan “SIAPA SAYA?” Dan belahan otorisasi yaitu tanggapan 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 dipakai dengan benar, ada beberapa pelanggaran privasi.
Apa itu Vulnerability IDOR?
Pertama, perlu memahami pedoman 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 gampang ditemukan (pengujian otomatis atau pengujian manual).
Kerentanan IDOR diilustrasikan dalam gambar berikut antara pengguna dan server.
Tes Vulnerability IDOR yang efektif & cepat
Anda sanggup memakai tab Riwayat HTTP Burp Suite untuk mengusut semua permintaan. Fitur HTTP History yang memperlihatkan semua kemudian lintas antara perangkat (browser, ponsel, tablet) dan server aplikasi. Anda juga sanggup memakai fitur ruang lingkup Burp Suite untuk pengujian cepat. Karena fitur lingkup sanggup berkhasiat untuk menciptakan daftar sasaran 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 sanggup menambahkan cakupan yang relevan dengan mengklik kanan pada permintaan.
Anda sanggup mengedit nilai lingkup pemanis ini sesuai dengan cakupan yang diberikan sebagai berikut
Terakhir, Anda harus melaksanakan pemfilteran berikut di tab Riwayat HTTP dengan menentukan "Tampilkan hanya item dalam-lingkup"
Ini akan membantu Anda untuk memahami tugas menyerupai hanya baca, normal, super dll dalam aplikasi dengan lebih baik.
Capture all requests!
Contoh ditemukan dalam agenda pribadi. Kartu kredit ditambahkan ketika melaksanakan pembelian di aplikasi seluler. Setelah usul diuji, sanggup dipikirkan bahwa tidak ada kerentanan. Tetapi ketika pembelian kedua dilakukan, layar pemilihan kartu kredit terlihat dan kerentanan IDOR ketika ini. Saat menentukan kartu kredit di sini, aplikasi akan mengirimkan id kartu kredit ke server dalam usul dan usul ini memang menyediakan untuk mengakses data kartu kredit pengguna lain yang mengubah id kartu kredit.
Dalam agenda langsung lainnya, aplikasi web menyertakan sistem pesan dalam aplikasi. Pengguna sanggup mengirim pesan ke pengguna lain dan menambahkan pengguna lain ke pesan sendiri. Ketika pengguna mencoba mengakses salah satu pesannya sendiri, usul pergi ke “/ messages / 5955” dan id pesan milik sendiri tampaknya “5955”. Demikian juga, ketika mencoba mengakses pesan pengguna lain dengan menciptakan usul ke "/ messages / 5955", pesan itu tidak diakses. Ketika pengguna ingin menambahkan pengguna lain ke pesannya sendiri, muncul usul menyerupai 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 usul ini diperiksa, pengguna sanggup menambahkan dirinya ke pesan pengguna lain dan mengakses semua pesan.
Selain itu, tugas 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 berkhasiat selama fase deteksi kelemahan. Makara pertama-tama, Anda harus memahami aplikasi ini dengan dalam!
Bagaimana cara menemukan titik injeksi?
Jika Anda beruntung, Anda hanya sanggup melihat usul yang diotorisasi, yang harus dilihat oleh pengguna admin dalam file javascript. Karena itu, arahan sumber dan terutama file javascript harus dianalisis dengan baik.
Selain itu, Anda sanggup mencari versi usang aplikasi web di "archive.org" dan Anda sanggup menemukan usul yang berkhasiat dalam file javascript usang atau Anda sanggup mencari usul di mesin pencari memakai dorks.
Dalam beberapa kasus, nilai id tidak unik menyerupai 1, 2, 3, 100, 1000 dll, nilai id ini sanggup dikodekan atau nilai hash. Jika Anda menghadapi nilai yang disandikan, Anda sanggup menguji kerentanan IDOR dengan mendekode nilai yang disandikan. Jika Anda menghadapi nilai hash, Anda harus menguji apakah nilai hash yaitu nilai yang sanggup diakses atau diprediksi. Dalam masalah lain, Anda sanggup mengakses nilai hash di header "Referrer", sehingga skenario ini sanggup direplikasi.
Misalnya, Anda tidak sanggup mengakses objek pengguna lain tetapi Anda sanggup menemukan nilai id hash objek dalam arahan sumber halaman objek, Anda sanggup menemukan id hash objek ke dalam pesan dalam aplikasi dari pengguna korban (ini akan mengurangi dampaknya bug). Jadi, Anda sanggup menciptakan 2 akun uji sebagai X dan Y, kemudian mencoba nilai id hash X dalam usul Y di Riwayat Bersendawa.
Jika kami akan menyentuh topik lain, beberapa usul aplikasi mungkin menciptakan Anda takut. Misalnya, usul SmartSheet yang berisi lebih dari satu parameter tampaknya terlalu rumit.
Jika Anda ingin menemukan titik injeksi dalam usul ini, Anda sanggup memakai alat perbandingan Burp Suite. Anda harus mengklik kanan pada usul dan menentukan opsi "Kirim ke Pembanding". Kemudian Anda sanggup menciptakan usul yang sama untuk memakai objek lain dan mengirim ke pembanding.
Ketika Anda mengunjungi alat pembanding dan mengklik tombol "Kata", Anda akan disajikan dengan jendela daerah titik-titik perubahan.
Anda sanggup memakai metode yang sama untuk respons HTTP dan Anda sanggup mengusut perbedaannya.
Interesting cases for IDOR bugs
Manipulate the create requests
Beberapa aplikasi menciptakan id di sisi klien dan kemudian mengirim usul buat in ke server. Nilai id ini sanggup berupa angka menyerupai "-1", "0" atau apa pun. Nilai id yang ada berubah dengan id objek yang dibentuk sebelumnya. Makara Anda sanggup menghapus / mengedit objek pengguna lain memakai kerentanan IDOR.
Jika Anda tidak melihat parameter menyerupai "id", "user_id", "value", "pid", "post_id" ketika menciptakan objek, Anda harus menambahkannya dan mengujinya sendiri. Anda sanggup menemukan nama kunci parameter dengan menghapus atau mengedit objek apa pun di aplikasi.
Blind IDOR
Dalam masalah lain, Anda sanggup menemukan kerentanan IDOR tetapi Anda mungkin tidak menyadarinya. Misalnya, jikalau Anda mengubah warta objek di aplikasi, Anda akan mendapat email yang menyertakan warta objek. Jadi, jikalau Anda mencoba mengubah warta objek pengguna lain, Anda tidak sanggup mengakses apa pun dalam respons HTTP tetapi Anda sanggup mengakses warta objek dengan email. Anda sanggup menyebutnya "Blind IDOR".
Combine them!
Dampak bug IDOR sanggup diubah dan kami akan menyentuhnya. Dalam beberapa kasus, kerentanan IDOR sanggup membantu Anda dengan memicu kerentanan lain yang tidak sanggup dieksploitasi. Jika Anda menemukan kerentanan IDOR yang tidak penting menyerupai mengedit pengguna yang bukan publik & nama file tidak penting dan Anda ingin meningkatkan dampak bug Anda, Anda sanggup memakai bug self-XSS. Kerentanan XSS diri yang Anda temukan ketika pengujian aplikasi web umumnya di luar jangkauan dan tidak dihargai. Namun, Anda sanggup menggabungkan kerentanan XSS diri dengan kerentanan IDOR lain dan Anda sanggup mengirimkan laporan sebagai “IDOR + Stored XSS”. Dengan cara ini Anda sanggup 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 menyerupai pengaturan ulang kata sandi, perubahan kata sandi, pemulihan akun. Makara pertama-tama, Anda harus mengusut tautan di email Anda dan parameter di dalamnya. Kemudian, Anda sanggup menangkap usul pengaturan ulang kata sandi dan mengusut parameter dengan alat proxy apa pun. Kami telah melihat berkali-kali nilai "id pengguna" dalam usul ini dan kami sanggup dengan gampang mengambil alih ke akun pengguna lain.
Pada ketika yang sama, itu yaitu hal penting yang mengambil alih akun dengan nilai header yang dikirim dalam permintaan. Terlihat bahwa beberapa nilai header menyerupai "X-User-ID", "X-UID" dari lingkungan pengujian dan debug diubah. Sehingga pengguna sanggup bertindak menyerupai pengguna mana pun dan berhasil mengambil alih akun.
HPP Bug
Dalam masalah yang jarang terjadi, Anda sanggup menguji kerentanan HPP (HTTP Parameter Pollution) untuk pengujian IDOR dengan menambahkan parameter yang sama sekali lagi dalam usul Anda. Contoh dari ini: https://www.youtube.com/watch?v=kIVefiDrWUw
Create valid request
Anda harus yakin bahwa usul kirim ke server sudah benar. Jika Anda mencoba mengirim usul pengguna dengan pengguna lain, Anda harus yakin bahwa nilai "CSRF-Token" usul ini valid. Makara Anda harus memasukkan "CSRF-Token" pengguna lain ke dalam permintaan. Kalau tidak, Anda akan mendapat kesalahan sebab nilai token tidak cocok. Ini sanggup menciptakan Anda menyesatkan.
Demikian juga, jikalau usul Anda yang diuji yaitu XHR (Permintaan HTTP XML), Anda harus mengusut validasi parameter header "Tipe Konten" dalam usul Anda. Selain itu, usul aplikasi mungkin mempunyai tajuk khusus menyerupai "W-User-Id", "X-User-Id", "User-Token" dll. Jika Anda ingin melaksanakan tes yang benar dan sempurna, Anda harus mengirim semua tajuk yang dipakai oleh aplikasi sudah benar.
Useful tools
Seperti yang kami sebutkan sebelumnya, Anda sanggup memakai fitur Burp Suite. Anda juga sanggup memakai plugin Burp Suite untuk pengujian kerentanan IDOR, menyerupai "Authz", "AuthMatrix" dan "Authorize".
Plugin Authz menyediakan untuk melihat respons usul untuk pengguna lain. Jadi, Anda sanggup mengirim usul pengguna X ke Authz dan mencoba mengakses responsnya sebagai pengguna Y. Anda juga sanggup menambahkan tajuk khusus untuk kerentanan IDOR pengujian menyerupai "X-CSRF-Token". Anda sanggup mendapatkannya dari BApp Store atau di alamat ini.
Plugin AuthMatrix memungkinkan Anda untuk melaksanakan investigasi otorisasi dengan mendaftarkan nilai cookie atau nilai header untuk tugas dalam aplikasi. Anda sanggup mendapatkannya dari BApp Store dan jikalau Anda ingin warta lebih lanjut untuk plugin yang manis ini, buka di sini.
Jika Anda mempunyai usul API, Anda sanggup memakai plugin Wsdler untuk Burp Suite, SoapUI, Postman, dll. Anda sanggup mencoba semua DAPATKAN, POST, PUT, HAPUS, usul PATCH dan sukses dan uji API cepat memakai alat.
Impact of IDOR vulnerabilities
Kerentanan IDOR nampak sebagai “VARI tergantung pada dampak” di Bugcrowd VRT sebab pengaruhnya sangat bergantung pada bug yang Anda kirim.
Tetapi kami telah menciptakan daftar ihwal dampak kerentanan IDOR menurut 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 langsung / publik (seperti tiket, faktur, warta pembayaran)
P3 - Akses / hapus / ubah data langsung (info langsung terbatas: nama, alamat, dll.)
P4 - Akses semua data yang tidak penting
Dampak kerentanan IDOR tergantung pada budi manajer program.
How to prevent IDOR vulnerabilities?
Pertama, Anda harus mengontrol semua usul normal, ajax, dan API ketika menciptakan aplikasi. Misalnya, dapatkah pengguna hanya baca menulis sesuatu di aplikasi? Atau bisakah pengguna non-admin mengakses dan menciptakan token API yang hanya dibentuk oleh pengguna admin? Jadi, untuk menguji semua kerentanan IDOR, Anda harus berpikir menyerupai seorang peretas.
Anda sanggup memperlihatkan izin pada aplikasi Anda untuk semua titik akhir. Jika titik selesai "privatesection" Anda meliputi usul API menyerupai "/ api / privatesection / admin", "/ api / privatesection / console", "/ api / privatesection / token", Anda sanggup memblokir titik selesai untuk pengguna non-admin.
Selain itu, untuk menciptakan pekerjaan penyerang lebih sulit dan bahkan kadang kala bahkan untuk mencegahnya, Anda sanggup memakai fungsi hash dan memakai nilai hash alih-alih angka atau string normal.