Trik Block SQLi, XSS, dan RCE di Level Nginx Tanpa Merusak Kolom Pencarian Blog Koding

Halo sobat Melanjutkan cerita dari artikel sebelumnya, setelah WAF Nginx berhasil saya pasang di server klien, muncul kendala baru yang tidak terduga. Salah satu klien saya mengelola sebuah blog edukasi koding dan pemrograman. Dua hari setelah WAF terpasang, beliau menghubungi saya karena ada laporan dari pembaca websitenya.

Laporannya begini: pembaca tidak bisa menggunakan kolom pencarian di blog tersebut setiap kali mencari tutorial yang mengandung kata seperti INSERT, SELECT, atau sintaks koding lainnya. Begitu tombol cari diklik, halaman malah menampilkan error penolakan dari server.

Saya langsung sadar bahwa aturan WAF awal yang saya pasang ternyata terlalu “agresif” dan memicu *False Positive*. WAF menganggap pembaca yang sedang mencari tutorial koding sebagai hacker yang sedang mencoba melakukan SQL Injection atau XSS. Bagi sebuah blog edukasi koding, tentu ini sangat mengganggu kenyamanan pengunjung.

Mencari Solusi: Regex yang Presisi dan Context-Aware

Saya tidak ingin mematikan WAF karena risiko serangan tetap ada. Jadi, saya membedah kembali struktur pola serangan (*attack pattern*). Peretas asli biasanya tidak hanya mengirim kata insert, melainkan pola eksekusi utuh seperti insert into atau gabungan query union select. Sementara pembaca blog klien saya hanya mengetik satu kata kunci saja di kolom pencarian.

Berdasarkan temuan tersebut, saya memperbarui aturan Nginx di server klien menjadi seperti ini:

# Aturan WAF Presisi untuk Blog Teknis Klien - rahmatriyanto.com

# 1. SQLi: Hanya blokir jika ada gabungan perintah SQL yang utuh
if ($args ~* "(union.*select|insert.*into|delete.*from|update.*set)") {
    return 404;
}

# 2. XSS: Blokir tag script atau karakter berbahaya yang di-encode
if ($args ~* "(javascript:|%27|%22|%3C|%3E)") {
    return 404;
}

# 3. RCE: Hanya blokir jika fungsi PHP dipanggil dengan tanda kurung '('
if ($args ~* "(eval|base64_encode|proc_open|passthru|shell_exec|system|exec|popen)(\(|\%28)") {
    return 404;
}

Masalah Selesai, Klien Senang

Setelah aturan di atas dipasang, masalah *False Positive* di website klien tuntas seketika. Pembaca blog mereka bisa kembali mencari tutorial koding dengan bebas lewat URL ?s=insert, sementara jika ada bot jahat yang menembak URL ?s=insert+into+users, Nginx akan langsung memblokirnya.

Pelajaran berharga bagi saya: keamanan yang baik itu harus presisi dan tidak boleh merusak fungsi utama dari aplikasi klien kita!