Apa itu otorisasi dalam aplikasi web / seluler?
Manajemen sesi aplikasi web / seluler sangat penting bagi pengguna akhir. Manajemen sesi terdiri dari dua bab penting, otentikasi dan otorisasi. Bagian otentikasi yaitu balasan dari pertanyaan “SIAPA SAYA?” Dan bab otorisasi yaitu balasan 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 ajaran 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 menyidik 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 mempunyai kegunaan 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 suplemen 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 aktivitas pribadi. Kartu kredit ditambahkan ketika melaksanakan pembelian di aplikasi seluler. Setelah seruan 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 seruan dan seruan ini memang menyediakan untuk mengakses data kartu kredit pengguna lain yang mengubah id kartu kredit.
Dalam aktivitas 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, seruan pergi ke “/ messages / 5955” dan id pesan milik sendiri tampaknya “5955”. Demikian juga, ketika mencoba mengakses pesan pengguna lain dengan menciptakan seruan ke "/ messages / 5955", pesan itu tidak diakses. Ketika pengguna ingin menambahkan pengguna lain ke pesannya sendiri, muncul seruan 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 seruan 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 mempunyai kegunaan selama fase deteksi kelemahan. Kaprikornus pertama-tama, Anda harus memahami aplikasi ini dengan dalam!
Bagaimana cara menemukan titik injeksi?
Jika Anda beruntung, Anda hanya sanggup melihat seruan yang diotorisasi, yang harus dilihat oleh pengguna admin dalam file javascript. Karena itu, aba-aba 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 seruan yang mempunyai kegunaan dalam file javascript usang atau Anda sanggup mencari seruan 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 aba-aba 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 seruan Y di Riwayat Bersendawa.
Jika kami akan menyentuh topik lain, beberapa seruan aplikasi mungkin menciptakan Anda takut. Misalnya, seruan SmartSheet yang berisi lebih dari satu parameter tampaknya terlalu rumit.
Jika Anda ingin menemukan titik injeksi dalam seruan ini, Anda sanggup memakai alat perbandingan Burp Suite. Anda harus mengklik kanan pada seruan dan menentukan opsi "Kirim ke Pembanding". Kemudian Anda sanggup menciptakan seruan yang sama untuk memakai objek lain dan mengirim ke pembanding.
Ketika Anda mengunjungi alat pembanding dan mengklik tombol "Kata", Anda akan disajikan dengan jendela kawasan titik-titik perubahan.
Anda sanggup memakai metode yang sama untuk respons HTTP dan Anda sanggup menyidik perbedaannya.
Interesting cases for IDOR bugs
Manipulate the create requests
Beberapa aplikasi menciptakan id di sisi klien dan kemudian mengirim seruan 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. Kaprikornus 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, kalau Anda mengubah gosip objek di aplikasi, Anda akan mendapat email yang menyertakan gosip objek. Jadi, kalau Anda mencoba mengubah gosip objek pengguna lain, Anda tidak sanggup mengakses apa pun dalam respons HTTP tetapi Anda sanggup mengakses gosip 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. Kaprikornus pertama-tama, Anda harus menyidik tautan di email Anda dan parameter di dalamnya. Kemudian, Anda sanggup menangkap seruan pengaturan ulang kata sandi dan menyidik parameter dengan alat proxy apa pun. Kami telah melihat berkali-kali nilai "id pengguna" dalam seruan 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 seruan Anda. Contoh dari ini: https://www.youtube.com/watch?v=kIVefiDrWUw
Create valid request
Anda harus yakin bahwa seruan kirim ke server sudah benar. Jika Anda mencoba mengirim seruan pengguna dengan pengguna lain, Anda harus yakin bahwa nilai "CSRF-Token" seruan ini valid. Kaprikornus Anda harus memasukkan "CSRF-Token" pengguna lain ke dalam permintaan. Kalau tidak, Anda akan mendapat kesalahan alasannya yaitu nilai token tidak cocok. Ini sanggup menciptakan Anda menyesatkan.
Demikian juga, kalau seruan Anda yang diuji yaitu XHR (Permintaan HTTP XML), Anda harus menyidik validasi parameter header "Tipe Konten" dalam seruan Anda. Selain itu, seruan 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 seruan untuk pengguna lain. Jadi, Anda sanggup mengirim seruan 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 kalau Anda ingin gosip lebih lanjut untuk plugin yang anggun ini, buka di sini.
Jika Anda mempunyai seruan API, Anda sanggup memakai plugin Wsdler untuk Burp Suite, SoapUI, Postman, dll. Anda sanggup mencoba semua DAPATKAN, POST, PUT, HAPUS, seruan PATCH dan sukses dan uji API cepat memakai alat.
Impact of IDOR vulnerabilities
Kerentanan IDOR nampak sebagai “VARI tergantung pada dampak” di Bugcrowd VRT alasannya yaitu pengaruhnya sangat bergantung pada bug yang Anda kirim.
Tetapi kami telah menciptakan daftar perihal 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, gosip 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 kecerdikan manajer program.
How to prevent IDOR vulnerabilities?
Pertama, Anda harus mengontrol semua seruan 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 menawarkan izin pada aplikasi Anda untuk semua titik akhir. Jika titik simpulan "privatesection" Anda meliputi seruan API menyerupai "/ api / privatesection / admin", "/ api / privatesection / console", "/ api / privatesection / token", Anda sanggup memblokir titik simpulan 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.