Cerita dari Balik Layar: Ngoprek Pentest Web Aplikasi & API Perusahaan XYZ

Selama internship di bidang keamanan siber, saya nggak cuma stuck di depan dashboard SIEM buat triase alert. Ada dua project pentest yang cukup seru buat diceritain: satu web pentest ke Web Aplikasi perusahaan XYZ, satu lagi API pentest ke sistem inquiry data polis mereka.

Dua-duanya dilakukan secara resmi (authorized), dengan scope dan izin dari klien. Nama perusahaan, domain, dan detail teknis yang sensitif saya samarkan di tulisan ini — fokusnya lebih ke proses, metodologi, dan pelajaran yang bisa diambil, bukan ngebocorin data siapa-siapa.

Kenapa Dua Metode Sekaligus: Black Box vs Grey Box

Untuk pengujian LMS, kami pakai kombinasi Black Box Testing dan Grey Box Testing.

Black Box — penguji nggak dikasih akses apa pun, persis kayak penyerang dari luar. Ini dipakai buat memetakan attack surface: apa aja yang bisa dilihat dan dicoba orang random tanpa login.
Grey Box — penguji dikasih akun resmi (misalnya akun user biasa), buat mensimulasikan pengguna yang udah login. Ini penting karena banyak risiko baru justru muncul setelah seseorang berhasil masuk — dashboard, manajemen user, sampai fitur course management.

Kombinasi keduanya ngasih gambaran risiko yang jauh lebih lengkap dibanding cuma pakai satu pendekatan aja.

Alur Kerja: Dari Recon Sampai Automated Scanning

Alur pengujian LMS ini kira-kira begini:

Reconnaissance & Technology Fingerprinting — pakai dig, nslookup, httpx, WhatWeb, curl buat ngecek DNS/IP dan fingerprint teknologi server (framework, web server, versi, dsb).
Enumeration — pakai gau, Katana, ffuf, plus analisis JS source buat nemuin endpoint dan direktori yang mungkin nggak seharusnya publik.
Grey Box Testing — login pakai akun resmi, mapping dashboard, lalu pakai Burp Suite buat intercept traffic dan parameter tampering.
Automated Scanning — jalanin Nuclei (ribuan template) dan Xray (ratusan POC) buat nyisir kerentanan umum, lalu semua hasil otomatis divalidasi manual satu per satu — soalnya automated scanner itu cepat tapi rawan false positive.

Poin penting yang saya pegang selama proses ini: jangan percaya mentah-mentah hasil scanner. Setiap "temuan" dari Nuclei/Xray tetap dicek ulang manual sebelum masuk laporan.

Hasil di Sisi LMS: Semua Low, Tapi Tetap Penting

Dari pengujian LMS, ada 6 temuan yang terkonfirmasi — semuanya kategori Low/Informational, nggak ada yang kritis. Beberapa polanya:

File & konfigurasi yang kebuka ke publik — ada file konfigurasi internal yang harusnya diblokir tapi malah bisa diakses langsung lewat browser. Indikasi deployment hygiene yang kurang rapi.
Header & cookie security yang belum lengkap — aplikasi belum mengirim header keamanan standar (semacam HSTS, CSP, X-Frame-Options), dan cookie session belum full-secure.
Error disclosure & pengujian otorisasi — ada endpoint yang balikin error server, plus pengujian Broken Access Control antar-role yang sudah dilakukan tuntas (dan hasilnya: tidak ditemukan bukti akses data lintas akun yang berhasil).

Meskipun semua "cuma" Low, ini tetap layak dicatat — karena kombinasi beberapa temuan kecil kadang bisa jadi stepping stone buat serangan yang lebih besar kalau dibiarkan menumpuk.

Bagian Kedua: API Inquiry Polis — Studi Kasus IDOR

Ini bagian yang paling menarik secara teknis. Pengujian kedua fokus ke API integrasi yang dipakai buat proses inquiry data polis, dengan metode black-box API testing pakai Postman.

Alur singkatnya:

Client minta token dengan mengirim credential + signature.
Server menerbitkan access token yang berlaku sementara (belasan menit).
Client kirim nomor identifikasi data + token ke endpoint inquiry.
Server balikin link yang berisi data terkait.

Pertanyaan kunci yang jadi fokus pengujian: apakah server benar-benar memverifikasi SIAPA yang minta data, atau cuma ngecek APAKAH token-nya valid?

Dan jawabannya… server ternyata cuma ngecek validitas token, bukan kepemilikan datanya. Ini adalah pola klasik Insecure Direct Object Reference (IDOR) — masuk ke kategori API1:2023: Broken Object Level Authorization di OWASP API Security Top 10.

Singkatnya: selama token valid, server bakal proses request untuk identifier apa pun yang dikirim — termasuk milik pihak lain yang jelas di luar scope pengujian resmi. Karena nomor identifikasinya bersifat sekuensial, secara teori pola ini juga berpotensi disalahgunakan buat enumerasi data secara massal kalau nggak ada kontrol tambahan.

Temuan ini kami beri rating High, dengan CVSS 3.1 base score di kisaran 6.5 — vector-nya menunjukkan serangan bisa dilakukan dari jaringan, dengan kompleksitas rendah, dan berdampak tinggi ke aspek kerahasiaan data.

Klarifikasi Penting dari Klien

Menariknya, setelah dilaporkan, pihak klien memberi klarifikasi: pada saat pengujian, aplikasi ini memang baru punya satu role pengguna, jadi dari sisi desain sistem, akses semacam itu dianggap sesuai desain — bukan celah keamanan — dan temuan ini secara resmi mereka tolak (tidak dianggap vulnerability yang perlu diperbaiki).

Saya pikir ini justru poin belajar yang bagus: temuan teknis nggak selalu otomatis jadi "vulnerability" dalam konteks bisnis tertentu. Konteks arsitektur sistem, jumlah role, dan desain awal aplikasi ikut menentukan apakah sesuatu itu risiko nyata atau bukan. Tapi secara pola teknis, apa yang ditemukan tetap contoh nyata gimana IDOR bekerja — makanya tetap layak didokumentasikan sebagai materi pembelajaran.

Tools yang Dipakai

Kalau ditanya toolkit yang paling sering dipakai selama dua pengujian ini:

Postman — bikin dan simpan koleksi request API supaya bisa diulang persis sama.
Burp Suite — intercept, modifikasi, dan replay request/response secara terkontrol.
Browser & DevTools — buat verifikasi dampak nyata dari sebuah temuan.
dig, nslookup, httpx, WhatWeb, curl — reconnaissance dan fingerprinting.
gau, Katana, ffuf — crawling dan enumeration endpoint/direktori.
Nuclei & Xray — automated vulnerability scanning berbasis template/POC.

Yang saya pelajari: nggak ada satu tool pun yang cukup sendirian. Automated scanner bagus buat cakupan luas, tapi manual testing (dan logika berpikir "apa yang sebenarnya divalidasi server di sini?") yang justru nemuin temuan paling berdampak — dalam kasus ini, IDOR di API inquiry polis.

Penutup

Dua pengujian ini ngajarin saya beberapa hal:

Kombinasi black box + grey box itu penting — masing-masing nunjukin sisi risiko yang berbeda.
Automated scanning cuma titik awal, bukan hasil akhir — validasi manual tetap wajib.
Severity teknis dan risiko bisnis itu dua hal berbeda — sebuah temuan bisa CVSS tinggi tapi tetap "diterima" kalau konteks desain sistemnya memang begitu, dan sebaliknya.
IDOR itu sederhana tapi berbahaya — cuma soal "apakah server ngecek kepemilikan data, bukan cuma validitas token" — tapi dampaknya bisa besar kalau lolos ke production.

Makasih udah baca sampai sini. Kalau ada yang mau didiskusikan soal metodologi pentest, API security, atau OWASP Top 10, feel free drop komentar atau reach out 🙌