Di episode #7 sampai #10 kita sudah menyentuh sisi penyerang: OWASP Top 10, SQL Injection, XSS, CSRF. Pertanyaan yang muncul di kepala saya setelah itu: kalau semua serangan sudah dipelajari, bagaimana sebenarnya orang mengujinya secara legal di sistem nyata? Hari ini saya catat jawabannya — ethical hacking dan penetration testing, yaitu menembus sistem MILIK ORANG LAIN tapi dengan izin tertulis, waktu yang disepakati, dan laporan yang jujur.
Bagi saya sebagai programmer, ini penting karena selama ini mentalitas saya cuma satu: menulis kode yang jalan. Sekarang saya sadar ada peran yang tugasnya mencari celah SEBELUM penjahat menemukannya, dan proses kerjanya jauh lebih terstruktur daripada yang saya bayangkan waktu remaja dulu.
Apa itu ethical hacking
Bedanya dengan penyerang kriminal cuma tiga hal, tapi ketiganya menentukan segalanya: izin (ada surat persetujuan dari pemilik sistem), scope (IP, domain, dan fitur mana yang boleh diuji — di luar itu dilarang), dan tujuan (melaporkan temuan, bukan mengambil data untuk dijual). Tanpa ketiganya, aktivitas teknis yang sama persis berubah jadi tindak pidana.
Saya suka analogi ini: pengetesan keamanan itu seperti menyewa tukang untuk mendobrak pintu rumahmu sendiri. Dia memang mendobrak, tapi dia punya kunci cadangan, tahu jadwalnya, dan setelah selesai dia memberi daftar mana pintu yang harus diganti engselnya. Bandingkan dengan perampok — kemampuannya sama, niat dan izinnya yang membedakan.
Metodologi: tidak ada yang asal tembak
Ini yang paling mengubah cara pandang saya. Awalnya saya kira penetration test = langsung pakai tool. Ternyata separuh pekerjaannya adalah dokumen dan persiapan. Standar yang banyak dirujuk, PTES (Penetration Testing Execution Standard), membagi pekerjaan jadi tujuh tahap berurutan:
| Tahap (PTES) | Isi kerjanya |
|---|---|
| 1. Pre-engagement | Menyepakati scope, jadwal, kontak darurat, dan rules of engagement sebelum menyentuh apa pun |
| 2. Intelligence gathering | Rekognisi: informasi publik soal target (OSINT), pasif dulu baru aktif |
| 3. Threat modeling | Menentukan aset berharga dan skenario penyerang yang masuk akal |
| 4. Vulnerability analysis | Mengidentifikasi kelemahan, lalu memvalidasinya — bukan sekadar menyalin hasil scan |
| 5. Exploitation | Membuktikan celah itu benar-benar bisa dimanfaatkan, sesuai scope |
| 6. Post exploitation | Menilai dampak: kalau celah ini di tangan penjahat, apa yang bisa dia capai? |
| 7. Reporting | Menulis temuan, tingkat risiko, dan rekomendasi perbaikan |
Yang menarik buat saya: tahap 1 dan 7 adalah dokumen, bukan kode. Klien justru paling banyak membaca laporan di akhir — temuan tanpa rekomendasi yang bisa ditindaklanjuti itu tidak bernilai. NIST SP 800-115, panduan resmi dari NIST soal pengujian keamanan, juga menekankan hal yang sama: tekniknya banyak, tapi perencanaan dan analisis temuan yang menentukan kualitas.
Contoh alur kecil di web aplikasi
Misal saya diminta menguji aplikasi toko online milik klien. Urutannya kira-kira begini: kumpulkan informasi publik (subdomain, teknologi yang dipakai, halaman login), pindai untuk menemukan kandidat kelemahan, lalu validasi manual satu per satu — misalnya menguji apakah field pencarian rentan SQL Injection seperti yang kita bahas di episode #8, atau apakah ada XSS seperti di episode #9. Setiap temuan dicatat lengkap dengan bukti langkah reproduksi, lalu ditutup dengan rekomendasi: prepared statement, escape output, pasang Content Security Policy.
Poin yang saya garisbawahi untuk diri sendiri: validasi manual wajib. Scanner otomatis (Nikto, Nuclei, dan sejenisnya) bagus sebagai penggaruk, tapi sering memberi false positive. Menyalin hasil scan mentah-mentah ke laporan adalah kesalahan pemula yang paling mudah dikenali.
Legalitas: bab yang paling sering diabaikan pemula
Di Indonesia, UU ITE (UU No. 11/2008 sebagaimana diubah, terakhir melalui UU No. 1 Tahun 2024) pada Pasal 30 melarang setiap orang mengakses sistem elektronik milik orang lain tanpa hak atau melawan hukum; ancaman pidananya diatur di Pasal 46, mencapai 6 tahun penjara. Tidak ada pengecualian yang bunyinya “saya cuma iseng” atau “saya peneliti”. Karenanya izin tertulis bukan formalitas kantor — itu satu-satunya payung hukum saya.
- Pastikan ada surat atau email persetujuan yang menyebut target, rentang tanggal, dan batasan eksplisit.
- Uji hanya pada aset yang masuk scope. Satu IP di luar daftar bisa menggugurkan seluruh perlindungan.
- Hentikan dan hubungi kontak darurat kalau menemukan data sensitif nyata — jangan dilanjutkan mengumpulkan.
- Simpan jejak kerja (log, timestamp) sebagai bukti bahwa aktivitas terjadi dalam batas yang disepakati.
Bug bounty: jalur belajar yang dibayar
Bagi saya yang belum punya klien, jalur paling realistis adalah program bug bounty resmi: perusahaan membuka scope-nya sendiri lewat platform seperti HackerOne, Bugcrowd, atau Intigriti, dan peneliti yang menemukan celah dibayar sesuai tingkat keparahan. Laporan HackerOne untuk 2025 menyebut total pembayaran bounty mencapai $81 juta (naik 13% dibanding tahun sebelumnya), dengan 10 program teratas menyumbang $21,6 juta. Angka itu yang meyakinkan saya bahwa ini jalur karir nyata, bukan hobi.
Yang saya pelajari: program bounty punya aturan main sendiri — ada safe harbor (peneliti yang mengikuti aturan dilindungi), larangan mass assignment data pengguna lain, dan larangan DoS. Melanggar aturan itu membuat temuan tidak dibayar dan akun bisa diblokir, meski celahnya asli.
Yang tidak boleh saya lakukan
- Menguji sistem pihak ketiga tanpa izin, termasuk yang “kelihatannya tidak dijaga”. Ketiadaan peringatan bukan izin.
- Mengeksploitasi temuan di luar scope, mengambil data pengguna nyata, atau menyimpan akses setelah tes selesai.
- Menyebarkan detail celah sebelum masa disclosure yang disepakati habis — konsep responsible disclosure melindungi pengguna yang belum sempat diperbaiki.
Catatan penutup untuk diri sendiri: penetration testing bukan soal kehebatan menembus, tapi soal disiplin proses. Kemampuan teknis saya masih jauh (episode #19 soal incident response dan #21 soal analisis malware masih terasa berat), tapi paling tidak sekarang saya tahu kerangka kerjanya — dan di episode #23 kita akan masuk ke alat harian seorang tester: web proxy.
Sumber
- PTES — Penetration Testing Execution Standard v1.1: dokumen PDF resmi
- NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment (2008): nvlpubs.nist.gov
- OWASP Web Security Testing Guide (v4.2): owasp.github.io
- HackerOne Hacker-Powered Security Report 2025 (angka $81 juta): hackerone.com
- UU No. 11 Tahun 2008 jo. UU No. 1 Tahun 2024 tentang Informasi dan Transaksi Elektronik — Pasal 30 & Pasal 46
Komentar Terbaru