Embedded Files
"Tentukan apa yang ingin kamu capai, baru cari cara mencapainya."
Banyak bug hunter datang dengan harapan tinggi:
Menemukan celah, submit report, lalu dapat reward.
Namun sayangnya, banyak yang datang dengan mentalitas seperti mesin scanner atau robot. Klik semua tombol, inject semua payload, ubek semua fitur tanpa tahu sebenarnya sedang mencari apa, lalu berharap keberuntungan turun dari langit.
Apakah pendekatan seperti itu bisa berhasil? Bisa, tapi mungkin sesekali.
Tapi apakah bisa diandalkan untuk mendapatkan reward besar, berulang kali, di level kompetisi seperti Google, Microsoft, atau company raksasa lainnya? Jawabannya tidak.
Di level perusahaan raksasa, mayoritas bug umum hampir pasti sudah lebih dulu disapu oleh scanner otomatis, QA engineer, pentester internal, dan ratusan hunter lain yang datang sebelum kamu. Kalau pendekatanmu sama seperti mereka, asal klik dan coba-coba, kemungkinan besar kamu hanya akan menjadi satu dari banyak yang kehabisan celah.
Satu-satunya cara untuk menonjol adalah datang membawa arah. Bukan untuk sekadar melihat-lihat, tapi untuk membuktikan sesuatu. Bukan untuk eksplorasi acak, tapi untuk menjalankan sebuah misi:
“Saya ingin buktikan bahwa saya bisa ..........”
Dua Mindset yang Berseberangan
❌ Mindset yang kurang tepat:
"Coba-coba dulu aja. Siapa tahu nemu."
Tanpa arah. Tanpa tujuan. Tanpa ekspektasi realistis. Bahkan ketika akhirnya menemukan sesuatu, mereka sendiri belum tentu tahu nilainya.
✔️ Mindset yang harusnya kamu terapkan:
"Saya ingin buktikan viewer bisa eskalasi jadi editor." (PrivEsc)
"Saya ingin lihat email dari semua member classroom." (Leaked Email)
"Saya ingin pertahankan akses ke file google doc meski sudah dihapus dari project-nya." (Persistent Access)
Dengan mindset seperti ini, kamu datang bukan untuk coba-coba. Kamu datang untuk membuktikan sebuah hipotesis. Kamu membawa misi. Kamu tahu apa yang kamu cari dan kamu menyusun langkah logis untuk menuju ke sana (Exploit).
Mindset seperti ini bukan cuma membuat kamu terlihat lebih fokus, tapi benar-benar mengubah cara kamu mengeksekusi. Kamu tidak lagi menelusuri fitur secara acak. Kamu sedang membedah sistem berdasarkan satu dugaan yang spesifik.
Eksplorasimu jadi lebih terarah: kamu tahu fitur mana yang relevan, behavior apa yang mencurigakan, dan kapan waktunya berhenti atau lanjut eskalasi. Kamu tidak lagi mencari-cari bug, kamu sedang mengkonfirmasi sesuatu yang masuk akal untuk menjadi celah.
Dan ketika bug ditemukan, kamu tidak sekadar melaporkan “ada error”. Kamu bisa menjelaskan dengan yakin:
“Saya eksplorasi ini karena saya ingin membuktikan A, dan ternyata benar bisa dimanipulasi menjadi B.”
Itu bukan hasil kebetulan. Itu hasil dari menentukan goal di awal!
Mini Framework: Dari Goal ke Eksploitasi
Menentukan goal adalah langkah pertama. Tapi agar goal itu benar-benar mengarah pada eksploitasi yang valid, kamu perlu mengubahnya jadi eksplorasi yang terarah.
Mini framework yang bisa kamu terapkan:
GOAL → ASSUMPTION → TEST → RESULT
#1 - Goal
“Aset sensitif apa yang saya incar?”
“Akses kontrol apa yang ingin saya 'loncati'?”
dll
Semua dimulai dari sini. Kamu harus tahu dulu apa yang ingin kamu buktikan, bukan sekadar “mencari bug”. Setelah menentukan goal, semua eksperimenmu yang bahkan kelihatannya acak, akan punya arah. Berbeda dengan hunting tanpa goal, kali ini kamu tahu:
“Apa yang sedang saya kejar?”
“Kenapa saya mencoba hal ini?”
“Bagaimana ini mendekatkan saya ke goal awal saya?”
Kasus nyata saya:
Suatu ketika saya bug hunting di platform Google Apps Script (GAS). Pemilihan target ini pun tidak asal-asalan atau sedapatnya, melainkan bagian dari strategi dalam memilih target. Kamu bisa baca cara memilih target bug bounty di Strategi 7: 🔐 nanti.
Sedikit tentang Google Apps Script (GAS), sederhananya ini adalah kode editor online milik Google. Kita bisa "ngoding" bersama-sama secara online dengan cara mengundang akun lain sebagai collabolator. Mirip seperti Google Docs, kita bisa undang email lain untuk mengedit dokumen bersama-sama.
Lanjut, saat berada di target (GAS) saya menentukan sebuah goal:
"Saya sangat yakin, saya bisa mempertahankan akses ke project meskipun sudah diremove oleh pemilik."
#2 - Assumption
“Apa jalur tercepat atau paling masuk akal mencapai goal itu?”
Di tahap ini, kamu mulai membangun hipotesis teknis. Berdasarkan pemahaman flow sistem, kamu mencoba menebak jalur mana yang paling potensial untuk diuji. Oleh karena itu, memahami dulu bagaimana sistem bekerja secara normal sangatlah penting. Nanti akan dibahas pada Strategi 11: 🔐.
Kasus nyata saya:
Berangkat dari goal saya di awal:
"Saya sangat yakin, saya bisa mempertahankan akses ke project meskipun sudah diremove oleh pemilik."
Saya mulai membangun asumsi dengan hipotesis teknis.
"Asumsi saya, untuk bisa mempertahankan sebuah akses, berarti saya perlu...":
"Cari cara mengeksekusi sebuah function dari tempat lain, selain dari dalam project itu sendiri."
Dari asumsi tersebut, saya bisa pecah menjadi sebuah bagian-bagian kecil lagi:
"Saya akan coba jalankan sebuah function dan menangkap requestnya (potensi replay attack)"
"Saya akan coba menambahkan akun lain ke project saya yang lain, lalu mengubahnya dengan ID project target (potensi IDOR)"
"Saya akan memahami bagaimana proses deployment di Google Apps Script bekerja. Siapa tahu, function itu akan menjadi publik (potensi abuse risk)"
"Saya akan cek apakah function yang pernah di-deploy masih bisa diakses setelah saya dihapus dari project (potensi stale permission/cache)"
"Saya juga akan perhatikan apakah ada mekanisme fallback atau cache/token sisa yang bisa dieksploitasi (potensi persistent access via artifact lama)"
Semua asumsi di atas tidak muncul begitu saja secara kebetulan, untuk mencapai asumsi seperti di atas, lagi-lagi karena saya sudah sangat memahami bagaimana proses, akses kontrol, dan fitur normal dari Google Apps Script bekerja. Strategi 11: 🔐. memang se-krusial itu.
#3 - Test
“Bagaimana cara membuktikan asumsi ini?”
Tahap inilah kamu mulai eksplorasi teknis, mengumpulkan bukti dan mencoba berbagai pendekatan, tapi tetap mengarah ke goal awal. Tujuannya jelas:
Mengumpulkan bukti nyata yang bisa mendukung asumsi, sambil tetap fokus pada goal utama, yaitu mempertahankan akses ke project meskipun sudah diremove.
Kasus nyata saya:
Semua pengujian ini saya lakukan dengan mindset:
"Bukan sekadar membuktikan asumsi benar, tapi juga mencari celah di titik-titik yang sering diabaikan developer."
Ini adalah hasil pikiran dari Strategi 10: 🔐.
Setiap kali ada hasil yang tidak sesuai harapan, saya evaluasi ulang. Apakah ada logika yang terlewat, atau justru muncul ide jalur baru untuk diuji lagi.
Tahapan Test ini adalah fase di mana kreativitas dan kegigihan sangat dibutuhkan. Karena sering kali, hasil terbesar justru ditemukan di percobaan ke sekian, bukan di uji coba pertama. Semangat!
#4 - Result
“Bagaimana hasilnya?”
Saya selalu berharap berhasil. Tapi jika gagal, kembali ke asumsi, kembangkan ulang dan eksplorasi lagi.
Kasus nyata saya:
Akhirnya, setelah melalui berbagai uji coba dan eksplorasi, saya berhasil menemukan celah yang memungkinkan saya mengeksekusi function dari luar project (meskipun akses saya sudah dicabut oleh pemilik).
Dengan temuan ini, saya benar-benar bisa mempertahankan akses ke project Google Apps Script, bahkan setelah status saya sebagai kolaborator dihapus.
Tapi perjalanan tidak berhenti sampai situ. Mengingat prinsip dari Strategi 5: 🔐. Saya terus mencari kemungkinan lain untuk memperbesar impact temuan ini.
Framework GOAL → ASSUMPTION → TEST → RESULT ini tidak hanya berhenti setelah satu siklus, tapi terus berulang. Setiap keberhasilan justru membuka pintu menuju goal baru yang lebih tinggi.
Contohnya, meskipun saya sudah berhasil mengeksekusi function dari luar project setelah status kolaborator saya dihapus, saya sadar ada tantangan berikutnya:
"Saya perlu mengetahui daftar nama function-nya."
Maka, saya kembali membangun goal baru:
"Saya yakin bisa menemukan cara atau tempat lain untuk menampilkan list nama function dari project ini."
Prosesnya terus berulang:
Dari goal baru, saya susun lagi asumsi, lakukan testing, analisa hasil, dan bila berhasil, saya dorong lagi ke goal berikutnya hingga tercapai level eskalasi tertinggi dan impact maksimal.
Hasil akhirnya, saya berhasil. Saya menemukan dua kombinasi celah yang menjadi satu kesatuan Persistent Access in Google Apps Script:
Saya menemukan cara untuk mendapatkan list nama function secara real-time.
Saya juga menemukan cara untuk mengeksekusi function dari tempat lain, tanpa perlu akses langsung ke project
Boom! Celah persistent access yang jauh lebih berbahaya berhasil saya buktikan, lengkap dengan metode eskalasi dan dampak yang lebih luas.
Kamu bisa baca write-up lengkap tentang vulnerability P***** 🔐 yang saya temukan di sini.
Jadi?
Keberhasilan saya mendapatkan celah tersebut bukan hasil keberuntungan. Tapi hasil dari satu kalimat goal yang sangat spesifik di awal.
Inilah esensi dari strategi berbasis goal, kamu bisa tetap fleksibel dan kreatif, tapi semua langkahmu punya arah yang jelas dan berujung pada satu target yang solid.
Jadi, sebelum menyentuh kode atau membuka aplikasi target, ambil waktu satu menit untuk menulis satu kalimat:
“Saya ingin tahu apakah saya bisa ______”
Kalimat ini bukan sekadar pengantar eksplorasi, tapi penentu arah. Karena tanpa arah, kamu hanya berputar. Tapi dengan goal, kamu berburu dengan akurasi.
Semangat hunter! Ini baru strategi pertama. Kita masih punya 13 strategi lagi yang siap mengubah cara pandangmu terhadap bug bounty.
Di strategi berikutnya, kita akan bedah kenapa pakai metodologi pentest saat bug hunting, justru membunuh insting terbaikmu sendiri.
Saat ini kamu sedang menikmati versi gratis.
Untuk membuka semua bab dan konten eksklusif
segera upgrade ke versi premium sekarang juga.
Ada baiknya teman-teman juga memahami term of use ini.
Google Sites
Report abuse