Pelajaran dari Kasus SQL Injection pada Aplikasi Jadwal Salat Masjid

Beberapa waktu lalu, saya mendapat kabar yang cukup mengejutkan dari seorang teman. Masjid tempat ia bertugas menggunakan aplikasi jadwal salat berbasis web untuk menampilkan waktu salat dan pesan sunah harian di layar TV. Namun, pada suatu hari, tampilan tersebut tiba-tiba berubah secara misterius — nama masjid berganti, dan pesan sunahnya diganti dengan teks yang tidak semestinya.

Setelah dilakukan pemeriksaan, ternyata aplikasi tersebut menjadi korban serangan SQL Injection, sebuah jenis serangan yang menargetkan kelemahan pada sistem basis data.

🧨 Apa yang Terjadi?

Melalui investigasi sederhana, kami menemukan bahwa akar masalahnya berasal dari dua hal utama:

Directory Listing Aktif
Web server masih mengizinkan pengguna untuk melihat isi folder (directory listing). Akibatnya, siapa pun bisa dengan mudah melihat struktur direktori website, termasuk folder aplikasi yang digunakan.
Aplikasi Rentan SQL Injection
Di dalam folder tersebut, ada aplikasi jadwal salat yang masih menggunakan metode query mentah (raw query) tanpa perlindungan. Penyerang memanfaatkannya untuk menyisipkan perintah SQL berbahaya, dan berhasil memanipulasi data di database.

Hasilnya, tampilan pada layar TV masjid berubah — nama masjid dan teks sunah diganti sesuai keinginan si pelaku.

🛠️ Langkah Mitigasi yang Dilakukan

Sebagai langkah awal, saya segera melakukan tindakan mitigasi cepat untuk menghentikan potensi serangan lanjutan:

1. 🔒 Menonaktifkan Directory Listing

Dengan menambahkan konfigurasi berikut pada .htaccess:

Options -Indexes

Langkah ini mencegah siapa pun melihat isi folder melalui browser. Directory listing yang aktif sering menjadi pintu pertama untuk reconnaissance (pengintaian) oleh penyerang.

2. 🧱 Memindahkan Folder Aplikasi

Folder aplikasi yang sebelumnya berada di dalam public_html dipindahkan ke subdomain terpisah. Tujuannya agar tidak langsung terekspos ke internet dan hanya bisa diakses dari URL tertentu yang memang diperuntukkan.

Setelah dua langkah ini, tampilan aplikasi kembali normal dan serangan berhenti.

🧭 Pelajaran yang Didapat

Insiden ini menjadi pengingat bahwa keamanan aplikasi web bukan hanya soal menulis kode, tetapi juga mengelola konfigurasi dan struktur server dengan benar. Bahkan aplikasi sederhana seperti jadwal salat pun bisa menjadi target, terutama jika dibiarkan dengan pengaturan default.

Berikut beberapa langkah tambahan yang sebaiknya diterapkan agar aplikasi tetap aman:

🧰 Langkah Pencegahan SQL Injection dan Serangan Serupa

1. ✅ Gunakan Prepared Statements atau ORM

Hindari query mentah berbasis string. Gunakan prepared statements seperti berikut:

$stmt = $conn->prepare("SELECT * FROM users WHERE username = ? AND password = ?");
$stmt->bind_param("ss", $username, $password);
$stmt->execute();

Atau gunakan ORM (Object Relational Mapping) seperti Eloquent di Laravel untuk binding otomatis.

2. 🧩 Gunakan Framework Modern (Contoh: Laravel)

Framework seperti Laravel memiliki perlindungan SQL Injection bawaan, serta fitur keamanan lain seperti:

CSRF token untuk setiap form,
Validasi input yang kuat,
Struktur folder aman (semua file sensitif di luar public),
Error handling yang bisa disembunyikan di production.

Dengan mengikuti best practice Laravel, banyak celah keamanan dasar bisa tertutup otomatis.

3. 🚫 Matikan Display Error di Production

Jangan biarkan pesan error tampil ke pengguna, karena bisa membocorkan struktur query atau path file.

display_errors = Off
log_errors = On

4. 🔐 Gunakan File Permission Aman

Pastikan:

File: 644
Folder: 755
Tidak ada folder dengan 777

5. 🛡️ Aktifkan WAF (Web Application Firewall)

Aktifkan ModSecurity di cPanel atau gunakan layanan seperti Cloudflare WAF untuk memblokir serangan SQLi dan XSS secara otomatis.

6. 🗂️ Lindungi File Sensitif

Tambahkan aturan .htaccess untuk menolak akses file penting:

<FilesMatch "\.(env|sql|bak|config|ini|log|sh|php~)$">
    Deny from all
</FilesMatch>

7. 📦 Backup dan Monitoring Rutin

Lakukan backup otomatis dan simpan di lokasi terpisah.
Selain itu, pantau access.log dan error.log untuk mendeteksi pola serangan lebih dini.

💡 Penutup

Kasus sederhana ini menjadi pengingat bahwa:

🔸 Aplikasi kecil pun layak mendapatkan keamanan serius.
🔸 Kebocoran sering terjadi bukan karena “hebatnya hacker”, tapi karena “kelengahan developer”.

Membangun aplikasi dengan prinsip security by design akan menghemat banyak waktu dan tenaga di masa depan.
Jangan menunggu sampai layar TV masjid Anda menampilkan pesan dari hacker baru sadar pentingnya keamanan 😅.

📘 Kesimpulan Singkat

Masalah utama: Directory listing aktif & query rentan.
Mitigasi: Disable listing, pindahkan folder, audit query.
Pencegahan: Gunakan Laravel, prepared statements, WAF, validasi input, dan backup rutin.