Blog mendetail ini menjelaskan kasus bug bounty di dunia nyata di mana penulis menemukan kerentanan Insecure Direct Object Reference (IDOR) di aplikasi perbankan. Blog ini mencakup panduan lengkap tentang bagaimana manipulasi titik akhir, penggunaan kembali token, dan penyalahgunaan API mengarah pada penemuan, pembuktian konsep, dan pembayaran akhirnya. Artikel ini juga menyoroti alat yang digunakan, metodologi peretasan etis, dan pelajaran bagi calon pemburu bug bounty.
Kerentanan Referensi Objek Langsung (IDOR) yang Tidak Aman masih menjadi salah satu bug paling kritis dan bermanfaat dalam program bug bounty. Di blog ini, saya akan memandu Anda bagaimana saya menemukan IDOR di aplikasi perbankan nyata, memanipulasi titik akhir API, dan mengungkapkan bug tersebut secara bertanggung jawab untuk mendapatkan hadiah. Baik Anda seorang pemula maupun calon pemburu bug bounty, panduan ini penuh dengan wawasan dunia nyata.
Table of Contents
- Apa itu IDOR (Insecure Direct Object Reference)?
- Target Recon: Bagaimana Saya Menemukan Aplikasinya
- Menyiapkan Lingkungan Pengujian
- Titik Akhir yang Menarik Perhatianku
- Memanfaatkan Kerentanan
- Penggunaan Kembali Token dan Eksploitasi Lebih Lanjut
- Pelaporan dan Bug Bounty
- Pelajaran yang Dipetik dari Dunia Nyata
- Tanya Jawab Umum
Apa itu IDOR (Insecure Direct Object Reference)?
Kerentanan IDOR terjadi ketika aplikasi mengekspos akses langsung ke objek seperti berkas, catatan pengguna, atau data transaksi menggunakan input yang diberikan pengguna- tanpa pemeriksaan otorisasi yang tepat. Kerentanan ini memungkinkan penyerang mengakses data atau melakukan tindakan pada sumber daya yang seharusnya tidak diizinkan.
Contoh:
Jika Anda dapat mengakses transaksi Anda melalui:
Lalu mengubahnya menjadi:
...dan mendapatkan data pengguna lain adalah IDOR klasik.
Target Recon: Bagaimana Saya Menemukan Aplikasnya
Saya memulai pengintaian saya pada program bug bounty pribadi yang mencakup aplikasi perbankan berbasis web dan seluler. Aplikasi seluler (Android) ini memiliki beberapa API menarik yang berinteraksi dengan transaksi pengguna, profil, dan layanan pembayaran internal.
Langkah-langkah:
- Mengunduh APK.
- Menggunakan MobSF dan Jadx untuk mendekompilasi aplikasi.
- Melihat titik akhir dan token yang dikodekan secara keras.
Menyiapkan Lingkungan Pengujian
Saya mengatur:
- Burp Suite untuk mencegat dan memodifikasi permintaan.
- Frida untuk instrumentasi runtime jika diperlukan.
- Emulator Android yang telah di-root untuk pengujian tanpa memengaruhi perangkat saya yang sebenarnya.
- Postman untuk permintaan API yang berulang.
Titik Akhir yang Menarik Perhatianku
Saya melihat titik akhir ini digunakan untuk mengambil data transaksi:
Authorization: Bearer <TOKEN>
Ketika saya mencegat permintaan di Burp dan mengubah ID transaksi ke nomor lain, saya mendapatkan... data transaksi pengguna lain. Bendera merah: Tidak ada kontrol akses tingkat objek!
Memanfaatkan Kerentanan
Saya mengonfirmasi bug tersebut dengan:
- Mengubah ID transaksi secara berulang.
- Mengotomatiskan penggunaan Burp Intruder dan memeriksa respons.
- Memvalidasi bahwa data tersebut milik pengguna yang berbeda (nama, jumlah, stempel waktu).
Server tidak pernah memeriksa apakah saya pemilik transaksi. Itu IDOR yang baku.
Penggunaan Kembali Token dan Eksploitasi Lebih Lanjut
Menariknya, token JWT yang sama juga dapat digunakan kembali untuk titik akhir lainnya:
API menggunakan ID numerik dan bukan UUID, yang membuat enumerasi lebih mudah. Saya berhasil:
- Lihat info kartu pengguna lain (4 digit terakhir, nama)
- Akses data KYC
- Ekstrak saldo akun
Pelaporan dan Bug Bounty
Saya mengirimkan laporan terperinci melalui platform dengan:
- Replikasi langkah demi langkah
- Tangkapan layar dan contoh cURL
- Penilaian risiko
Tingkat Keparahan: Kritis (P1)
Hadiah: $3.500
Perusahaan memperbaiki kerentanan dengan menerapkan otorisasi tingkat objek dan beralih ke UUID untuk referensi.
Pelajaran yang Dipetik dari Dunia Nyata
| Aspek | Keterangan |
|---|---|
| Jenis Kerentanan | Referensi Objek Langsung yang Tidak Aman (IDOR) |
| Permukaan Serangan | Titik akhir API seluler |
| Alat yang digunakan | Burp Suite, Postman, MobSF, Frida |
| Remediasi | Pemeriksaan kontrol akses + UUID |
| Bug Bounty | $3.500 |
Menemukan kerentanan IDOR dalam aplikasi perbankan mengajarkan saya kekuatan analisis titik akhir yang mendalam dan pengungkapan yang bertanggung jawab. Bug-bug ini mungkin tampak sederhana, tetapi dapat berdampak serius ketika data keuangan atau pribadi terekspos. Jika Anda baru memulai dengan bug bounty, menguasai pengujian API, logika otorisasi, dan menggunakan alat yang tepat dapat membantu Anda menemukan bug yang berdampak. Mulailah dari yang kecil, tetaplah beretika, dan teruslah belajar-setiap permintaan bisa jadi menyembunyikan hadiah besar.
Tanya Jawab Umum (FAQ)
Apa itu IDOR dalam bug bounty?
IDOR, atau Insecure Direct Object Reference, adalah kerentanan di mana penyerang memanipulasi input (seperti ID) untuk mengakses data tanpa izin tanpa pemeriksaan izin yang tepat. Ini adalah salah satu masalah yang paling sering dieksploitasi dalam program bug bounty.
Bagaimana IDOR dieksploitasi dalam aplikasi perbankan?
Pemburu bug menyadap panggilan API dan memodifikasi ID transaksi, berhasil mengakses data pengguna lain karena kurangnya pemeriksaan otorisasi-perilaku IDOR klasik.
Alat apa yang membantu mengidentifikasi kerentanan IDOR?
Burp Suite, Postman, MobSF, Frida, dan emulator atau alat proxy yang di-root membantu mengidentifikasi dan mengeksploitasi kerentanan IDOR di aplikasi seluler atau web.
Apakah IDOR masih relevan pada tahun 2025?
Ya, IDOR masih merupakan bug yang umum dan kritis. Banyak API, terutama yang berbasis seluler, masih belum memiliki pemeriksaan otorisasi tingkat objek yang memadai, sehingga rentan.
Bisakah Anda mengeksploitasi IDOR tanpa autentikasi?
Ya, tetapi dalam sebagian besar skenario dunia nyata seperti aplikasi perbankan, IDOR ditemukan di area yang diautentikasi di mana terdapat penggunaan kembali token atau logika otorisasi yang buruk.
Bagaimana Anda memperbaiki kerentanan IDOR?
Terapkan kontrol akses tingkat objek, validasi kepemilikan sisi server, dan hindari ID yang dapat diprediksi (gunakan UUID).
Berapa hadiah yang dibayarkan untuk IDOR dalam cerita ini?
Peneliti tersebut diberi penghargaan $3.500 karena secara bertanggung jawab mengungkapkan kerentanan kritis dalam aplikasi perbankan.
Apakah mengubah ID numerik dianggap ilegal?
Jika dilakukan pada aplikasi produksi langsung tanpa izin, ya. Namun, pada program bug bounty atau dengan persetujuan, hal itu legal dan merupakan bagian dari peretasan etis.
Mengapa API sering memiliki masalah IDOR?
API mengutamakan fungsionalitas dan kecepatan. Seringkali, pengembang mengabaikan penerapan kontrol akses yang tepat untuk setiap titik akhir objek, yang menyebabkan IDOR.
Apa saja tanda-tanda potensi IDOR?
ID objek yang dapat diprediksi atau berurutan, terutama di titik akhir API, merupakan tanda umum. Jika tidak ada validasi pengguna, itu pertanda buruk.
Bisakah IDOR ditemukan menggunakan Burp Intruder?
Ya. Burp Intruder dapat membantu mengotomatiskan pengujian ID untuk enumerasi dan mengidentifikasi titik akses yang tidak sah.
Apa perbedaan antara IDOR dan kontrol akses yang rusak?
IDOR adalah jenis khusus dari kontrol akses yang rusak di mana referensi objek (seperti ID pengguna atau jalur file) tidak dilindungi dengan benar.
Apakah aplikasi seluler rentan terhadap IDOR?
Ya. Aplikasi seluler sering kali menggunakan API dengan referensi objek yang dapat dimanipulasi, terutama jika logikanya ditangani di sisi klien.
Bagaimana penggunaan UUID membantu mencegah IDOR?
UUID sulit ditebak dan acak, membuat enumerasi menjadi sulit dan mencegah penyerang menemukan referensi yang valid.
Apakah IDOR dapat menyebabkan pengambilalihan akun?
Tidak secara langsung, tetapi dapat mengekspos data sensitif seperti token atau info pengguna yang dapat membantu eksploitasi lebih lanjut atau rekayasa sosial.
Haruskah pengembang memvalidasi akses pada setiap titik akhir?
Ya. Validasi tingkat objek harus diterapkan pada setiap permintaan untuk memastikan pengguna hanya mengakses data yang mereka berwenang.
Bagaimana cara menguji IDOR pada target bug bounty?
Fokus pada API yang diautentikasi, uji dengan memodifikasi ID objek, dan cari respons kontrol akses yang tidak konsisten.
Apakah IDOR umum dalam GraphQL atau REST API?
Ya. Baik GraphQL maupun REST API dapat rentan jika kontrol akses tidak diterapkan dengan benar di tingkat objek.
Apa cara yang etis untuk melaporkan bug IDOR?
Gunakan platform bug bounty atau saluran pengungkapan yang bertanggung jawab. Sertakan langkah-langkah replikasi yang terperinci, penjelasan risiko, dan saran mitigasi.
Berapa lama waktu yang dibutuhkan untuk menemukan IDOR?
Bervariasi. Terkadang beberapa menit, jika kontrol akses aplikasi lemah, atau lebih lama, tergantung kompleksitas dan perilaku titik akhir.
Bisakah Anda menemukan IDOR dengan Postman?
Ya, terutama di API. Postman memungkinkan manipulasi permintaan yang mudah, sehingga efektif untuk eksplorasi IDOR.
Apa itu penggunaan kembali token di IDOR?
Menggunakan token autentikasi yang sama di seluruh titik akhir untuk mengakses objek yang tidak sah jika kontrol akses tidak diterapkan dengan benar.
Mengapa otorisasi lebih penting daripada autentikasi?
Autentikasi memverifikasi identitas Anda. Otorisasi memeriksa apa yang diizinkan untuk Anda lakukan-yang sangat penting dalam mencegah IDOR.
.png)
.jpeg)
0 Komentar