catatan metode Penetrasi

hari ini saya mendapat kesempatan belajar dan berdiskusi terkait metode pengujian web yang dipaparkan oleh teman saya taufik hidayat (topan) dimana dia menceritakan terkait temuan-temuan serta metode yang digunakan dalam pengujian web app. Acuan yang dia pakai dalam pengujian web mengikuti OWASP top 10 orang yang sudah lama di dunia siber pasti tau tapi baut saya yang awam ini merupakan istilah yang sangat jarang terdengar sempat sesekali dengar namun belum sempat ngulik lebih lanjut. lanjut ke pembahasan dari yang dipaparkan topan dia menemukan celah celah yang dapat jadi sasaran empuk para hacker nantinya jika applikasi sudah di publish.

Topan menjelaskan bahwa pengujian web (penetration testing) dilakukan dengan menggabungkan dua pendekatan utama:

• Black Box Testing: Pengujian tanpa akun atau akses kode sumber sama sekali. Tujuannya memposisikan diri persis seperti peretas dari luar internet untuk memetakan attack surface (titik masuk yang terlihat secara publik).
• Grey Box Testing: Pengujian menggunakan akun pengguna yang sah. Tujuannya menguji apakah seorang pengguna biasa bisa melompat pagar untuk mengakses modul administratif atau data milik pengguna lain.

Untuk mempercepat pemetaan, digunakan berbagai tools seperti httpx dan WhatWeb untuk reconnaissance teknologi, ffuf dan Katana untuk mencari direktori tersembunyi, hingga Nuclei dan Burp Suite untuk menganalisis parameter web secara mendalam.Studi Kasus Temuan: Mengapa Hal Sederhana Bisa Berbahaya?

Studi Kasus Temuan: Mengapa Hal Sederhana Bisa Berbahaya?

Dari pengujian yang dipaparkan Topan, ada dua jenis temuan menarik yang membuka mata saya mengenai pentingnya pengujian keamanan: Terkadang celah keamanan bukan berasal dari kesalahan koding yang rumit, melainkan dari konfigurasi server yang belum rapi:

• File .htaccess dan .DS_Store Terbuka: File konfigurasi dan metadata sistem yang lupa disembunyikan sehingga bisa diunduh langsung lewat browser.
• Header Keamanan yang Hilang: Ketiadaan header seperti Content Security Policy (CSP) dan Strict-Transport-Security (HSTS), serta cookie sesi yang belum diberi atribut Secure.

Meskipun dampaknya tergolong Low, celah-celah kecil ini memberikan informasi teknis berharga bagi penyerang untuk merancang serangan lanjutan. Salah satu poin paling krusial yang dijelaskan adalah Insecure Direct Object Reference (IDOR).Sederhananya, bayangkan Anda masuk ke akun perbankan/asuransi milik Anda, lalu sistem memberikan link untuk melihat tagihan dengan parameter nomor polis:

.../inquiry?policyNo=1001

Jika celah IDOR terjadi:

• Anda cukup mengganti angka tersebut menjadi policyNo=1002.
• Jika server hanya mengecek apakah Anda punya token login tanpa memvalidasi apakah nomor polis tersebut benar milik Anda, maka server akan menampilkan data pribadi (nama, tanggal lahir, status polis) milik nasabah nomor 1002.

Eksploitasi semacam ini sangat berbahaya karena penyerang dapat membuat skrip otomatis untuk menyedot (scraping) seluruh data nasabah secara masal.

Pelajaran Berharga untuk Pengembang Aplikasi

Sesi diskusi ini memberi saya pemahaman baru: membangun aplikasi bukan hanya soal fitur berjalan lancar (functional), melainkan bagaimana memastikan data di dalamnya terlindungi (secure by design).

Tiga poin penting yang saya catat dari sesi ini:

1. Validasi Otorisasi di Sisi Server: Jangan pernah percaya parameter input yang dikirim dari client-side. Server wajib memvalidasi kepemilikan data sebelum mengembalikannya.
2. Bersihkan File Sisa Sebelum Rilis: Pastikan file konfigurasi, riwayat version control, dan directory listing dimatikan pada server produksi.
3. Automasi vs Verifikasi Manual: Alat pemindai otomatis (scanner) sangat membantu, tetapi pengujian manual (seperti manipulasi logika bisnis menggunakan Burp Suite) tetap menjadi kunci untuk menemukan celah logika yang tidak terbaca oleh bot.