Bug bounty adalah program di mana perusahaan mengundang peneliti keamanan (security researcher) untuk mencari celah di sistemnya, dengan aturan yang jelas, lalu memberi hadiah untuk laporan yang valid. Bayangin museum yang mengundang ahli kunci untuk menguji pintunya. Aturannya tertulis: cuma pintu-pintu ini, jangan pecahkan kaca, dan kalau ketemu kelemahan, lapor diam-diam ke kantor keamanan, bukan diumumkan di media sosial. Yang menemukan duluan dapat hadiah. Di pelajaran ini kamu ada di sisi pemilik program: museumnya, bukan ahli kuncinya.
🧪 Tebakan cepat: dua peneliti melaporkan bug IDOR yang sama persis, selisih dua hari. Siapa yang dapat bounty: dua-duanya, yang pertama, atau yang laporannya paling rapi? Tebak dulu, jawabannya ada di bagian "Triage: memilah laporan yang masuk".
Responsible disclosure dan bug bounty
Responsible disclosure (sekarang lebih sering disebut coordinated disclosure) adalah cara melaporkan celah: peneliti memberi tahu pemilik sistem secara pribadi dulu, memberi waktu untuk memperbaiki, lalu detailnya baru dipublikasikan setelah perbaikan rilis atau setelah tenggat yang disepakati. Tenggat yang umum dipakai 90 hari.
Ada dua bentuk program:
- VDP (Vulnerability Disclosure Program): jalur resmi untuk melapor, tanpa hadiah uang. Tim kecil biasanya mulai dari sini.
- Bug bounty: VDP plus hadiah yang besarnya tergantung severity.
Banyak perusahaan menjalankan program lewat platform seperti HackerOne, Bugcrowd, Intigriti, atau YesWeHack, yang membantu menampung laporan, triage, dan pembayaran. Proyek open source bisa memakai private vulnerability reporting di GitHub Security Advisories.
Menulis kebijakan program: scope, aturan, safe harbor
Sebelum menerima satu laporan pun, pemilik program menulis kebijakannya. Ini kebijakan TokoKita yang dipakai Lab:
| Bagian | Isi |
|---|---|
| In scope | app.tokokita.id, api.tokokita.id |
| Out of scope | blog.tokokita.id (dikelola pihak ketiga), payment gateway pihak ketiga |
| Dilarang | DoS atau stress test, phishing dan social engineering ke karyawan, membaca atau menyimpan data user lain melebihi yang perlu untuk membuktikan bug |
| Wajib | pakai akun uji milik sendiri, berhenti dan lapor begitu menyentuh data orang lain |
| Safe harbor | riset yang mengikuti aturan ini gak akan kami tuntut secara hukum |
| Respons | balasan pertama maksimal 2 hari kerja, triage maksimal 5 hari kerja |
| Disclosure | detail boleh dipublikasikan setelah perbaikan rilis, paling lama 90 hari sejak laporan |
- Scope menjawab "apa yang boleh diuji". Tanpa scope tertulis, kamu akan menerima laporan tentang situs yang bahkan bukan milikmu.
- Aturan melindungi user dan sistemmu selama pengujian.
- Safe harbor adalah janji tertulis gak menuntut peneliti yang mengikuti aturan. Tanpa itu, peneliti yang jujur memilih diam.
Kasih tahu dunia ke mana harus melapor lewat file security.txt (RFC 9116) di https://tokokita.id/.well-known/security.txt:
Contact: mailto:[email protected]
Expires: 2027-06-30T00:00:00.000Z
Policy: https://tokokita.id/security-policy
Preferred-Languages: id, en
Acknowledgments: https://tokokita.id/hall-of-fame
ContactdanExpireswajib. Yang lain opsional.Expiressebaiknya kurang dari setahun ke depan, biar file yang lupa diperbarui gak dipercaya selamanya.Policymenunjuk ke kebijakan di atas,Acknowledgmentske halaman ucapan terima kasih untuk peneliti.
Triage: memilah laporan yang masuk
Triage adalah memutuskan status tiap laporan. Empat status yang paling sering dipakai:
- Valid: celah nyata, di dalam scope. Dapat severity, target perbaikan, dan bounty.
- Duplicate: celah yang sama sudah dilaporkan orang lain lebih dulu. Bounty jatuh ke laporan pertama.
- Out of scope: target atau tekniknya di luar kebijakan. Gak dapat bounty, tapi kalau temuannya nyata tetap diteruskan ke yang mengelola.
- Informative: informasinya benar, tapi gak menunjukkan dampak keamanan yang perlu diperbaiki segera.
Lima laporan di Lab:
| # | Laporan | Skor CVSS | Status |
|---|---|---|---|
| 101 | IDOR: ganti id di api.tokokita.id/orders/{id}, order user lain terlihat |
6,5 | Valid, Medium |
| 102 | IDOR yang sama di endpoint yang sama, dua hari kemudian, peneliti lain | 6,5 | Duplicate dari #101 |
| 103 | XSS di kolom komentar blog.tokokita.id |
Out of scope | |
| 104 | header X-Powered-By: Express terlihat, tanpa dampak yang ditunjukkan |
Informative | |
| 105 | SQL injection di api.tokokita.id/search, tanpa login bisa membaca dan mengubah database |
9,8 | Valid, Critical |
Jadi yang dapat bounty adalah peneliti pertama, #101. Laporan #102 berstatus Duplicate, serapi apa pun tulisannya. Itu jawaban tebakannya.
Severity dan waktu respons
Severity dihitung pakai CVSS (Common Vulnerability Scoring System), skor 0,0 sampai 10,0 dari hal seperti: bisa dari internet atau gak, perlu login atau gak, dan data apa yang kena. Skornya dipetakan ke tingkat, dan tiap tingkat punya janji waktu dan hadiah di kebijakan:
| CVSS | Severity | Target perbaikan | Bounty TokoKita |
|---|---|---|---|
| 0,0 | None | ||
| 0,1 sampai 3,9 | Low | 90 hari | Rp500.000 |
| 4,0 sampai 6,9 | Medium | 60 hari | Rp1.500.000 |
| 7,0 sampai 8,9 | High | 30 hari | Rp5.000.000 |
| 9,0 sampai 10,0 | Critical | 7 hari | Rp15.000.000 |
Angka waktu dan hadiah di tabel ini contoh dari kebijakan TokoKita; tiap program menentukan sendiri. Yang penting ditulis di depan, lalu ditepati: peneliti yang dibalas cepat dan dibayar sesuai janji akan melapor lagi.
⚠️ Jebakan yang sering ketemu
- Gak punya scope tertulis. Laporan berdatangan tentang domain pihak ketiga, dan kamu gak punya dasar untuk menolaknya.
- Diam berminggu-minggu. Peneliti yang gak dibalas cenderung mempublikasikan sendiri. Balas maksimal 2 hari kerja, walau cuma "sudah kami terima".
- Gak ada safe harbor. Peneliti yang jujur takut dituntut dan memilih gak melapor. Yang tetap mencari celahmu justru penyerang.
- Menandai duplikat tanpa bukti. Sebutkan nomor laporan pertamanya (misalnya "Duplicate dari #101") supaya keputusanmu bisa dicek.
TL;DR: Bug bounty mengundang peneliti mencari celah dengan aturan, dan membayar laporan yang valid; tanpa hadiah namanya VDP. Responsible atau coordinated disclosure berarti lapor diam-diam dulu, beri waktu perbaikan (umumnya 90 hari), baru publikasi. Sebagai pemilik program, tulis scope, aturan, safe harbor, janji waktu respons, dan pasang security.txt dengan Contact dan Expires. Triage tiap laporan jadi Valid, Duplicate (bounty untuk yang pertama), Out of scope, atau Informative, lalu nilai severity-nya pakai CVSS: Low 0,1 sampai 3,9, Medium 4,0 sampai 6,9, High 7,0 sampai 8,9, Critical 9,0 sampai 10,0. Platform populer: HackerOne dan Bugcrowd.
