My Experience with Bug Bounty Programs

Waktu gue pertama kali daftar ke platform bug bounty, gue pikir ini jalan pintas buat cuan sambil belajar. Satu tahun kemudian gue sadar: ini lebih mirip maraton di tengah padang pasir. Banyak yang nyerah di kilometer pertama.

Gue sendiri nyaris berhenti setelah tiga bulan pertama. Satu laporan gue ditolak mentah-mentah karena duplicate. Satu lagi ditolak karena kurang bukti. Gue ngerasa gagal total dan sempet nanya ke diri sendiri, "Apa gue beneran cocok di sini?"

Tapi setelah ngobrol sama beberapa orang yang udah lebih dulu jalan, gue sadar kalau pengalaman gagal di awal itu normal. Bahkan universal. Di tulisan ini, gue mau bagi perjalanan pribadi gue di dunia bug bounty: apa yang gue pelajari, kesalahan yang gue bikin, dan tips biat lo gak ngalamin pahit yang sama.

Platform Pertama: Jangan Langsung Kejar yang Besar

Banyak orang baru langsung daftar ke program eksklusif yang hadiahnya gede, dengan harapan dapet banyak. Nyatanya, program semacam itu udah penuh peneliti kawakan yang puluhan kali lebih cepet.

Gue mulai dari HackerOne dan Bugcrowd, tepatnya di program publik yang relatif sepi. Targetnya sederhana: situs kecil, layanan yang gak terlalu populer, dan batasan yang jelas. Di sini gue belajar dasar tanpa tekanan saingan yang gila-gilaan.

Pelajaran pertama gue: semakin kecil dan baru programnya, semakin tinggi peluang lo dapet temuan orisinal. Setelah tiga bulan, gue baru pindah ke program yang lebih ramai.

Satu Laporan Baik Lebih Berharga dari Sepuluh Laporan Setengah Jadi

Kesalahan paling mahal gue di awal adalah buru-buru lapor. Begitu nemu sesuatu yang kelihatan aneh, gue langsung kirim laporan dengan deskripsi dua baris. Akhirnya ditolak karena kurang jelas.

Sekarang gue pakai rumus simpel buat setiap laporan:

1. 1Jelaskan apa yang lo temuin dengan kalimat yang bisa dipahami orang teknis maupun non-teknis.
2. 2Beri langkah reproduksi yang jelas, dari awal sampai akhir. Kalau perlu sertakan request asli dan responsenya.
3. 3Jelaskan dampaknya. Kenapa ini berbahaya? Apa yang bisa dilakukan penyerang?
4. 4Kalau bisa, kasih saran perbaikan. Gak harus sempurna, tapi tunjukin lo udah mikir.

Laporan yang lengkap itu mahal nilainya. Tim keamanan di sisi penerima laporan selalu sibuk. Kalau lo bisa nunjukin bukti yang jelas, laporan lo diproses duluan. Itu pengalaman langsung gue.

Duplicate Itu Bukan Kegagalan

Gue pernah ngalamin masa di mana lima laporan berturut-turut kena duplicate. Rasanya kayak ditampar berkali-kali. Tapi dari situ gue belajar dua hal penting.

Pertama, duplicate artinya lo nemuin sesuatu yang nyata. Itu bukti kalau insting lo udah mulai jalan. Kedua, duplicate artinya lo perlu cepetan atau nyari sudut pandang yang belum kepikiran orang lain.

Sekarang gue liat duplicate sebagai sinyal, bukan hukuman. Kalau lo terus-terusan kena duplicate di satu area, itu tandanya area itu rame — saatnya geser ke tempat lain.

Bagaimana Gue Mulai: Bukan Cuma Tools, Tapi Pola Pikir

Di awal, gue pikir makin banyak tools yang gue punya, makin gede peluang. Gue download semua scanner otomatis, jalankan, dan dapat ratusan temuan. Tapi setelah ditelusuri, sebagian besar cuma noise.

Tools itu penting, tapi otak lebih penting. Ini urutan yang sekarang gue pakai:

1. 1Pahami aplikasi dulu. Buka secara manual, klik setiap tombol, baca setiap response. Jangan langsung jalanin scanner.
2. 2Identifikasi area yang kelihatan kompleks. Fungsionalitas yang banyak langkah atau banyak input biasanya punya permukaan serangan yang lebih luas.
3. 3Catat setiap endpoint, parameter, dan role yang berbeda.
4. 4Baru pakai tools untuk mempercepat, bukan sebagai pengganti otak.

Pola ini pelan tapi pasti ngasih hasil yang lebih konsisten daripada semprot-scanning.

Kerja Sama dan Kolaborasi

Bug bounty bukan kompetisi individu murni. Beberapa temuan terbaik gue justru datang dari ngobrol sama orang lain. Kadang lo mentok ngeliat satu bug, terus temen lo kasih sudut pandang yang gak kepikiran.

Gue juga sering baca laporan yang udah di-disclose. Dari situ gue belajar pola, teknik, dan cara nulis laporan yang bagus. Ini sumber belajar gratis yang sering diabaikan.

Jangan pelit ngasih tips ke pemula juga. Semakin lo jelasin sesuatu ke orang lain, semakin lo paham sendiri.

Satu Temuan yang Paling Gue Banggain

Gak ada yang spektakuler sebenarnya. Tapi ada satu temuan yang paling gue inget karena prosesnya panjang.

Gue lagi ngutak-ngatik satu aplikasi kecil yang fiturnya cuma upload dan share file. Di permukaan, gak ada yang menarik. Tapi setelah ngubek-ngubek beberapa jam, gue sadar kalau proses rename file setelah upload punya celah. Nama file yang lo ganti bisa dimanipulasi buat ngarah ke direktori lain.

Gue langsung mikir, "Ini path traversal." Tapi gue perlu bukti. Dua jam berikutnya gue habisin buat bikin payload yang benar-benar jalan. Setelah berhasil, gue tulis laporan detail dengan semua bukti. Seminggu kemudian laporan diterima dengan bounty pertengahan.

Pelajaran dari sini: fitur yang keliatan sepele sering jadi pintu masuk bug yang serius.

Kegagalan Bukan Akhir

Gue pernah ngerasa pengen berhenti total setelah sebulan gak dapet apa-apa. Setiap laporan ditolak, setiap submission gak dibales, dan gue mulai ngerasa ini bukan tempat gue.

Tapi ada satu mentor yang bilang ke gue, "Bug bounty itu permainan volume dengan kualitas. Lo harus tetep jalan, tapi sambil terus ningkatin kualitas." Gue ikutin saran itu. Satu laporan per minggu, gak peduli diterima atau tidak. Pelan-pelan, kualitas naik dan hasil mulai keliatan.

Kalau lo lagi di posisi itu sekarang, inget: setback itu bagian dari proses. Bukan berarti lo gak mampu.

Tools Utama yang Gue Pakai

Ini toolkit yang selalu gue bawa di setiap sesi bug hunting:

1. 1Burp Suite Community — proxy untuk nangkep dan manipulasi request.
2. 2Nmap buatan scanning singkat untuk cek surface awal.
3. 3Dirsearch dan ffuf, dua tool untuk directory busting.
4. 4Catatan pribadi gue sendiri — daftar payload yang pernah jalan, daftar endpoint yang sering dicek, dan daftar kesalahan yang pernah gue lakukan.

Gak perlu 50 tools. Tiga atau empat yang lo paham bener itu udah cukup.

Mulai dari Mana Kalau Lo Baru Banget

Kalau lo belum pernah nyentuh bug bounty sama sekali, ini langkah yang gue rekomendasiin.

1. 1Daftar di platform publik. HackerOne atau Bugcrowd adalah dua tempat yang ramah pemula.
2. 2Buka bagian yang berisi laporan yang sudah di-disclose. Baca 10 laporan pertama, pelajari formatnya.
3. 3Pilih satu program publik yang gak terlalu ramai. Jangan yang ada banyak hadiah tinggi, karena saingannya udah banyak.
4. 4Eksplorasi aplikasi itu secara manual dulu. Catat semua fitur, semua endpoint, semua parameter.
5. 5Coba satu teknik, misalnya cek IDOR atau XSS dasar. Jangan coba banyak teknik sekaligus.
6. 6Kalau nemu sesuatu yang mencurigakan, dokumentasiin dengan baik. Walaupun mungkin gak diterima, itu latihan yang berharga.

Ulangi langkah 4 sampai 6 setiap minggu, walau cuma satu sesi. Konsistensi itu kunci, bukan kecepatan.

Penutup: Perjalanan Panjang Itu Sendiri Hadiahnya

Bug bounty bukan jalan cepat kaya. Beberapa orang memang dapet banyak dalam waktu singkat, tapi itu pengecualian, bukan aturan. Kebanyakan orang, termasuk gue, ngelewatin proses panjang: gagal, belajar, gagal lagi, baru mulai ngerti.

Tapi justru proses itu yang paling berharga. Karena di setiap kegagalan lo belajar sesuatu yang gak diajarin di kursus manapun. Dan ketika akhirnya lo dapet temuan pertama yang diterima, rasanya gak ada yang ngalahin.

Kalau lo baru mulai dan lagi ragu, inget ini: semua orang yang sekarang jago dulunya juga pernah ngerasa kayak lo. Mereka cuma gak berhenti.

Ada pengalaman pribadi di bug bounty yang mau lo bagi? Tulis di komentar. Dari cerita-cerita sederhana itulah ilmu paling mahal lahir.

#BugBounty #Cybersecurity #InfoSec #Belajar