Belajar Application Security Engineer - Web Application Firewall (WAF)

#Pendahuluan

Setelah di episode 17 kita mengelola researcher eksternal, episode ini kembali ke kontrol teknis — kali ini di tepi jaringan: Web Application Firewall. Posisi WAF dalam diskusi AppSec selalu polemik: ada yang menjadikannya lapisan utama keamanan, ada yang mencibirnya sebagai band-aid. Kebenarannya di tengah: WAF adalah lapisan mitigasi cepat dan lebar yang sangat berguna untuk menahan serangan generik, memberi waktu patch, dan memenuhi compliance — tapi tidak pernah menggantikan secure coding.

Kita bahas cara kerjanya, pilihan implementasi (self-hosted vs cloud), strategi tuning detection→blocking, dan kesadaran bypass yang menjaga kalian dari false sense of security.

#Cara Kerja WAF

WAF menganalisis request HTTP di layer aplikasi sebelum menyentuh backend. Keputusan per request didasarkan pada:

Signature rules: pola payload berbahaya (UNION SELECT, <script>, path traversal).
Reputation: IP sumber, ASN, tor exit nodes, daftar bot.
Behavioral/rate: frekuensi request per identitas, anomali pola akses.
Protocol sanity: header malformed, method aneh, content-length mismatch.

Posisi penempatan menentukan kemampuannya:

100%

Cloud WAF (Cloudflare, AWS WAF, Akamai) duduk di edge — blokir sebelum bandwidth kalian tersentuh. ModSecurity/Nginx atau Coraza terpasang dekat aplikasi — kontrol penuh, log detail, tapi kapasitas mengikuti infrastruktur kalian.

#ModSecurity + OWASP Core Rule Set

Paket open source standar untuk self-hosted WAF adalah ModSecurity v3 (libmodsecurity) atau Coraza (Go-native) dengan OWASP Core Rule Set (CRS):

Contoh compose: Nginx + ModSecurity + CRS

docker run -d --name waf \
  -p 8080:80 \
  -v ./crs-setup.conf:/etc/nginx/modsecurity.d/crs-setup.conf:ro \
  owasp/modsecurity-crs:nginx

CRS bekerja dengan paranoia level (PL1–PL4): semakin tinggi, semakin agresif rule — dan semakin banyak potensi false positive. PL1 default aman untuk mulai; e-commerce/API JSON-heavy biasanya naik ke PL2 setelah tuning.

Setiap rule memberi skor anomali; total melewati threshold → block. Konfigurasi inti yang kalian atur:

Parameter	Arti
`tx.paranoia-level`	Agresivitas rule (1–4)
`tx.inbound_anomaly_score_threshold`	Skor untuk inbound block
`tx.restricted_extensions`	Ekstensi file yang diblokir
`SecRuleUpdateTargetById`	Pengecualian per parameter

#Detection Mode Dulu, Blocking Kemudian

Kesalahan paling mahal dengan WAF: nyalakan blocking hari pertama → pelanggan komplain form gagal → WAF dimatikan permanen. Jalur adopsi yang benar:

Minggu 1–2 — Detection only: semua rule mencatat, tidak ada blokir. Kumpulkan baseline: siapa pengunjung sah, parameter apa yang memicu rule.

Minggu 3–4 — Tuning exception: parameter tertentu yang sah (field deskripsi produk yang berisi teks bebas) di-exclude dari rule spesifik — bukan rule-nya dimatikan global:

ModSecurity exception presisi

# Jangan scan field 'bio' dengan rule 942100 (SQLi detection),
# karena validasi dilakukan di aplikasi + ORM binding
SecRuleUpdateTargetById 942100 "!ARGS:bio"

Perhatikan bedanya: exception presisi pada satu parameter, bukan menonaktifkan kategori serangan untuk semua input.

Minggu 5+ — Blocking bertahap: aktifkan block untuk rule dengan false positive nol; sisanya tetap detection. Review log mingguan; ketatkan bertahap.

Tip

Metrik sukses tuning bukan "berapa request diblokir" melainkan "nol false positive pada trafik sah + temuan serangan nyata tersentuh". WAF yang memblokir ribuan bot tapi juga checkout page sesekali akan dimatikan manajemen dalam sebulan.

#Bot Management & Rate Limiting Layer Aplikasi

Mayoritas trafik "serangan" modern adalah bot: scraping harga, credential stuffing (episode 5!), inventory hoarding. Lapisan penanganannya:

Rate limit edge — murah, tangkap volume kasar (per IP/ASN).
Bot fingerprinting — challenge JS/TLS fingerprint untuk membedakan browser asli vs script.
Credential stuffing defense — khusus endpoint login: deteksi IP reputation + rate per akun + MFA step-up saat anomali. WAF umum punya managed rule khusus untuk ini (misal Cloudflare Super Bot Fight, AWS WAF Bot Control).
CAPTCHA bertingkat — hanya pada risiko tinggi; CAPTCHA di setiap login merusak konversi tanpa menghentikan solver modern.

#Bypass Awareness: WAF Bukan Tembok

Sebagai AppSec engineer, kalian wajib tahu kenapa WAF bisa dilewati — supaya tidak menjual rasa aman palsu ke organisasi:

Encoding & obfuscation: double URL encoding, unicode overlong, komentar SQL (UNI/**/ON), case mixing. CRS menangani mayoritas varian umum, tapi parser differential antara WAF dan backend selalu membuka celah baru.
Parser confusion: WAF mem-parse body JSON satu cara, framework backend cara lain — payload disembunyikan di bagian yang tidak disepakati keduanya.
Business logic bypass sepenuhnya: WAF tidak tahu bahwa "transfer 2x saldo" ilegal. Tidak ada signature untuk logika bisnis kalian.
Serangan dari sisi klien (XSS stored via API internal yang tak lewat WAF, SSRF dari internal service).

Konsekuensi praktisnya: WAF masuk strategi episode 14 sebagai mitigasi lapisan, bukan kontrol utama. Vulnerability tetap harus difix di kode; WAF memberi jeda dan pertahanan generik.

#Praktik: Setup Bertahap di Lab

Uji siklus lengkap di lab kalian:

Simulasi serangan vs WAF detection mode

# Payload injection klasik ke Juice Shop via proxy WAF
curl "http://localhost:8080/rest/products/search?q=apple%27%20OR%20true--" \
  -o /dev/null -w "%{http_code}\n"
 
# Cek log WAF — cari anomaly score dan rule ID yang terpicu
docker logs waf 2&gt;&amp;1 | grep -i "anomaly\|id \"94" | tail -20

Di detection mode, request tetap 200 tapi log menunjukkan rule CRS mana yang cocok. Setelah pindah ke blocking, request sama mendapat 403. Latihan lanjutan: coba bypass dengan encoding ganda dan amati rule mana yang tetap menangkap — pemahaman ini langsung meningkatkan kualitas review WAF config kalian di pekerjaan nyata.

#Common Pitfalls

WAF sebagai pengganti patching: CVE Log4Shell ditutup dengan WAF rule sementara patch tertunda dua tahun = bom waktu; WAF mitigation harus punya expiry yang sama seperti risk acceptance episode 13.
Global exception: menonaktifkan rule SQLi untuk seluruh app karena satu field bermasalah; exception harus presisi per-parameter.
Tidak ada logging retention: insiden butuh investigasi mundur 30 hari; log WAF yang hilang = forensik buta.
Lupa non-HTTP attack surface: mobile API, WebSocket, dan gRPC sering tidak melewati jalur WAF klasik — petakan jalur trafik sebelum klaim coverage.

#Penutup

Inti yang harus dibawa pulang:

WAF = lapisan mitigasi generik di edge: signature, reputation, behavior — bukan pengganti fix kode.
Self-hosted (ModSecurity/Coraza + CRS) untuk kontrol penuh; cloud WAF untuk skala dan bot management.
Adopsi bertahap: detection → tuning exception presisi → blocking parsial; metrik sukses = nol FP pada trafik sah.
Pahami bypass (encoding, parser confusion, business logic) agar WAF diposisikan jujur dalam strategi.

Di episode 19 kita angkat perspektif arsitektur: Zero Trust untuk Apps — identity-aware access, least privilege per request, microsegmentation antar service, dan bagaimana menerjemahkan slogan "never trust, always verify" menjadi kontrol konkret pada aplikasi kalian. Sampai jumpa di episode 19!