Belajar Application Security Engineer - DAST & Dynamic Testing

#Pendahuluan

Setelah di episode 7 kita membangun SAST yang membaca kode, episode ini menguji aplikasi dari luar, saat berjalan: DAST (Dynamic Application Security Testing). Mengapa keduanya perlu? Karena melihat kode tidak sama dengan melihat perilaku. SAST bisa lolos melewati bug konfigurasi, interaksi antar service, header security hilang, dan business logic — semua itu hanya muncul ketika aplikasi benar-benar merespons request.

Tool utamanya dua: Burp Suite (standar industri untuk testing manual) dan OWASP ZAP (open source, kuat untuk otomasi). Kita praktikkan keduanya langsung pada lab Juice Shop dari episode 0.

#Cara Kerja DAST: Aplikasi sebagai Kotak Hitam

DAST tidak butuh kode sumber. Ia berinteraksi seperti penyerang sungguhan:

1. Crawling/spidering — memetakan endpoint yang bisa dijangkau lewat link & form.
2. Passive scanning — menganalisis trafik yang lewat tanpa mengirim payload agresif.
3. Active scanning — menginjeksi payload uji (XSS, SQLi, dll.) dan membaca responsnya.

Kekuatan dan kelemahannya simetris dengan SAST: menemukan apa pun yang terjadi (misconfig, header, injection nyata), tapi buta terhadap jalur kode yang tidak pernah dieksekusi selama scan. Cakupan DAST sepenuhnya ditentukan oleh seberapa lengkap crawler menjelajah — dan di sinilah masalah klasik SPA muncul.

#Burp Suite: Proxy Manual yang Menjadi Mata Kedua

Alur kerja dasar Burp Suite Community:

1. Jalankan Burp → proxy mendengarkan di 127.0.0.1:8080.
2. Arahkan browser ke proxy (via extension FoxyProxy atau config manual).
3. Install CA certificate Burp agar HTTPS bisa di-intercept.
4. Buka http://localhost:3000 (Juice Shop), navigasi halaman — setiap request masuk tab Proxy/HTTP history.

Yang membuat Burp tak tergantikan adalah kemampuan memodifikasi request in-flight:

GET /rest/products/search?q=apple HTTP/1.1
Host: localhost:3000
 
--- dimodifikasi menjadi ---
GET /rest/products/search?q=' OR true-- HTTP/1.1
Host: localhost:3000

Jika daftar produk yang dikembalikan berubah drastis (menampilkan semua baris termasuk yang hidden), kalian baru saja mengonfirmasi SQL injection secara dinamis — bukti jauh lebih kuat daripada dugaan statis.

Fitur yang wajib kalian kenal di fase ini: Repeater (kirim ulang request yang diedit berulang kali), Intruder (fuzzing parameter dengan wordlist), Decoder, dan Comparer.

#OWASP ZAP: DAST Otomatis Terbuka

ZAP punya mode otomatis yang cocok untuk pipeline. Tiga entry point-nya:

Praktikkan baseline scan terhadap lab kalian:

docker run --rm --network host -v $(pwd):/zap/wrk/:rw \
  ghcr.io/zaproxy/zaproxy:stable zap-baseline.py \
  -t http://localhost:3000 \
  -r report.html

Output-nya HTML + command exit code: 0 = tidak ada temuan, 1 = ada WARN, 2 = ada FAIL, 3 = gagal jalan. Konfigurasi -c rules.tsv memungkinkan kalian menandai rule mana yang FAIL/WARN/IGNORE per konteks aplikasi — inilah cara membuat gate yang proporsional.

#Authenticated Scanning

Mayoritas endpoint bernilai ada di balik login — scanner anonim hanya melihat permukaan. Dua pendekatan:

Context + auth script (Burp/ZAP): definisikan context (URL scope), beri kredensial test account, scanner login sendiri lalu crawl dalam sesi terautentikasi.

Pola token untuk API scanning: ZAP mendukung replays dengan header Authorization via authentication method "manual auth" + session token injection. Untuk API modern, sering lebih mudah scan via OpenAPI importer:

docker run --rm --network host ghcr.io/zaproxy/zaproxy:stable zap-api-scan.py \
  -t http://localhost:3000/api-docs/openapi.json \
  -f openapi \
  -r api-report.html

#Membaca Hasil Scan Tanpa Salah Prioritas

Hasil DAST mentah selalu membingungkan pemula. Kerangka triage cepat:

1. False positive dulu: XSS reflected kadang cuma echo tanpa eksekusi; verifikasi manual dengan Repeater sebelum melaporkan apa pun.
2. Kelompokkan per root cause: 40 temuan "header hilang" = satu temuan "perbaiki middleware header".
3. Prioritas kombinasi: dampak × kemudahan eksplotasi. SQLi di endpoint publik < 5 menit fix? Itu hari ini. Info disclosure versi server? Backlog.

Temuan tipikal Juice Shop pertama kali di-scan: CSP lemah, missing anti-CSRF di beberapa form, error stack leak, dan beberapa injection di search — sempurna untuk latihan triage kalian sebelum kita formalisasi proses remediasinya di episode 13.

#Common Pitfalls

• Mengandalkan spider untuk SPA: React/Vue merender via JavaScript; spider klasik buta. Gunakan ZAP AJAX Spider (headless browser) atau petakan endpoint via OpenAPI.
• Scan tanpa data: aplikasi e-commerce kosong menyembunyikan bug yang baru muncul dengan data realistis — seed staging database dengan data uji.
• Full scan di CI per PR: durasinya puluhan menit dan payload-nya agresif; baseline (passive) per PR, full scan mingguan malam.
• Melaporkan temuan mentah: hasil scanner bukan laporan; nilai kalian adalah validasi, root cause, dan rekomendasi fix.

#Penutup

Inti yang harus dibawa pulang:

• DAST menguji perilaku runtime — melengkapi SAST pada area yang statis tak terlihat: config, header, integrasi, injection nyata.
• Burp Suite = senjata manual (proxy, Repeater, Intruder); ZAP = mesin otomasi pipeline (baseline/full/API scan).
• Authenticated scanning wajib agar cakupan mencapai endpoint bernilai.
• Triase hasil: validasi manual, kelompokkan root cause, prioritas dampak×eksplotasi.

Di episode 9 kita beralih ke risiko yang bukan dari kode kalian: Dependencies & SCA — software composition analysis, SBOM, npm audit vs Trivy, licensing, dan cara membangun pipeline dependency scanning yang developer mau ikuti. Sampai jumpa di episode 9!