SQL Injection: Pengertian, Ciri, dan Cara Mencegahnya

SQL injection adalah celah keamanan yang muncul ketika aplikasi menyusun input pengguna langsung menjadi perintah SQL, sehingga basis data menjalankan teks yang seharusnya diperlakukan sebagai data biasa. Akibatnya, data bisa terbaca, berubah, atau terhapus oleh pihak yang tidak berhak. Artikel ini menjelaskan cara kerjanya secara konseptual, tanda-tanda yang bisa Anda kenali, dan langkah pencegahan yang terbukti efektif.

Apa Itu SQL Injection dan Mengapa Berbahaya?

Hampir setiap aplikasi web menyimpan data di basis data relasional seperti MySQL, PostgreSQL, atau SQL Server, dan berbicara dengannya lewat Structured Query Language (SQL). Menurut OWASP, SQL injection adalah penyisipan perintah SQL melalui data masukan dari klien ke aplikasi. Karena SQL tidak memisahkan data dan perintah secara tegas, basis data bisa menjalankan teks yang diselipkan penyerang bila aplikasi menggabungkannya mentah-mentah ke dalam query.

Dampaknya luas. OWASP mencatat kemungkinan bocornya data sensitif, login yang dapat dilewati bila pemeriksaan kredensial memakai SQL yang cacat, perubahan atau penghapusan data, hingga pengambilalihan server basis data. Tingkat keparahan sebenarnya bergantung pada hak akses akun basis data yang dipakai aplikasi dan pertahanan lain di sekelilingnya.

Kelas kerentanan ini juga masih besar. Pada OWASP Top 10 edisi 2025, kategori Injection berada di peringkat kelima (A05:2025) dan mencakup lebih dari 14 ribu CVE untuk SQL injection serta lebih dari 30 ribu untuk cross-site scripting. Pembahasan lengkap daftar tersebut ada di artikel pengertian OWASP dan OWASP Top 10.

Bagaimana SQL Injection Terjadi?

Akar masalahnya selalu sama: aplikasi membangun query dengan menyambung string, misalnya menempelkan isi kolom login atau kotak pencarian ke dalam teks perintah SQL. Struktur query yang dimaksud pengembang lalu bisa berubah karena input yang dibuat khusus. OWASP menggambarkan beberapa pola umum, yaitu mengubah kondisi sehingga query mengembalikan lebih banyak baris dari seharusnya, memotong sisa query dengan karakter komentar, dan pada basis data tertentu menambahkan perintah kedua setelah titik koma.

Celah ini bukan hanya milik form login. Parameter URL, kolom pencarian, filter dan pengurutan, cookie, serta header HTTP semuanya berpotensi menjadi pintu masuk bila nilainya berakhir di sebuah query tanpa pengikatan parameter. Stored procedure pun tidak otomatis aman bila di dalamnya ada penyambungan string.

Jenis-Jenis SQL Injection

Praktisi biasanya membagi serangan ini berdasarkan cara hasilnya terlihat oleh penyerang:

• In-band: hasil muncul di saluran yang sama dengan permintaan, misalnya data tampil di halaman atau pesan error basis data bocor ke layar.
• Blind (buta): aplikasi tidak menampilkan data atau error, tetapi perbedaan perilaku, seperti isi halaman atau waktu respons, tetap membocorkan informasi sedikit demi sedikit.
• Out-of-band: data dikirim lewat kanal lain, misalnya permintaan jaringan dari server basis data, dan hanya mungkin bila konfigurasi basis data mengizinkannya.

Perbedaan jenis ini penting bagi tim defensif. Blind injection tidak meninggalkan pesan error yang mencolok, sehingga deteksi harus bergantung pada log dan pola lalu lintas, bukan sekadar menunggu keluhan pengguna.

Ciri-Ciri Aplikasi Terkena SQL Injection

Tidak ada satu gejala yang pasti, tetapi tanda berikut layak diselidiki:

• Pesan error basis data, seperti kesalahan sintaks SQL, tampil di halaman atau tercatat setelah ada input tak lazim.
• Log aplikasi atau WAF memperlihatkan parameter berisi tanda kutip, karakter komentar, atau kata kunci SQL dalam jumlah tidak wajar.
• Respons melambat atau basis data tiba-tiba sibuk tanpa lonjakan pengguna yang masuk akal.
• Hasil pencarian atau daftar data tidak sesuai dengan kata kunci, atau muncul akun dan konten baru yang tidak dibuat admin.
• Ada kueri bervolume besar yang menarik banyak baris dari tabel sensitif oleh akun aplikasi.

Menemukan celah ini secara proaktif adalah bagian dari vulnerability assessment dan uji penetrasi. Pengujian harus dilakukan hanya pada sistem milik Anda sendiri atau yang Anda miliki izin tertulisnya, karena mengakses sistem elektronik orang lain tanpa hak melanggar Pasal 332 KUHP tentang akses ilegal (sebelumnya Pasal 30 UU ITE).

Cara Mencegah SQL Injection

OWASP SQL Injection Prevention Cheat Sheet menempatkan beberapa pertahanan utama, dan semuanya bertumpu pada satu prinsip: jangan pernah mencampur perintah dengan data.

1. Gunakan parameterized query (prepared statement)

Struktur SQL ditulis tetap, sedangkan nilai dari pengguna diikat lewat API basis data. Nilai itu selalu diperlakukan sebagai data. Contoh bentuknya:

SELECT id, nama FROM pengguna WHERE email = ?

Tanda tanya di atas diisi lewat pengikatan parameter, bukan lewat penyambungan string. ORM juga aman selama ia mengikat nilai dengan cara yang sama, dan menjadi rawan bila Anda menyisipkan potongan SQL mentah ke dalamnya.

2. Validasi dengan allow-list untuk bagian yang tidak bisa diparameterisasi

Nama tabel, nama kolom, dan kata kunci seperti ASC atau DESC tidak dapat diikat sebagai parameter. Petakan pilihan pengguna ke nilai tetap yang sudah Anda tentukan di aplikasi, lalu tolak sisanya.

3. Terapkan prinsip hak akses minimum

Akun basis data aplikasi tidak boleh bertipe DBA atau admin. Beri satu akun per aplikasi, batasi hak ubah dan hapus seperlunya. Ini tidak mencegah injeksi, tetapi memperkecil kerusakan bila celah tetap lolos.

4. Lapisan tambahan

• Jangan tampilkan pesan error basis data ke pengguna; catat di log internal saja.
• Escaping manual sangat tidak disarankan oleh OWASP karena bergantung pada dialek SQL dan mudah keliru.
• Gunakan Web Application Firewall sebagai lapisan tambahan, bukan pengganti perbaikan kode.
• Perbarui framework, plugin, dan pustaka akses data secara rutin, dan uji kode dengan analisis statis serta pengujian keamanan berkala.

Baca juga: Burp Suite: Pengertian, Fitur, dan Perbedaan Community dan Professional.

Pertanyaan yang Sering Diajukan

Apakah ORM otomatis kebal dari SQL injection?

Tidak otomatis. ORM aman bila ia mengikat nilai sebagai parameter. Fitur query mentah atau penyambungan string di dalam ORM tetap membuka celah yang sama.

Apakah WAF cukup untuk menghentikan SQL injection?

WAF membantu memblokir pola serangan yang dikenal, tetapi bukan perbaikan akar masalah. Kode yang menyambung string tetap rentan dan penyerang terus mencari cara melewati aturan filter.

Apakah aplikasi kecil atau website pribadi juga bisa menjadi target?

Bisa. Pemindaian otomatis menyasar siapa saja yang menjalankan kode atau plugin rentan, tanpa memandang ukuran situs.

Bagaimana cara belajar menguji SQL injection secara legal?

Gunakan lab milik sendiri atau platform latihan yang memang menyediakan target untuk diserang, dan jangan pernah mencoba pada sistem pihak lain tanpa izin tertulis.

Kesimpulan

SQL injection bertahan puluhan tahun karena penyebabnya sederhana: query yang dirakit dari input mentah. Obatnya pun sederhana dan sudah mapan, yaitu parameterized query, allow-list untuk identifier, hak akses basis data minimum, dan penanganan error yang tidak membocorkan detail. Jika Anda ingin mempelajari keamanan aplikasi web secara terstruktur dan legal, lihat program kursus Linuxhackingid. Untuk memahami di mana celah semacam ini berada dalam proses pengujian, baca juga pengertian penetration testing.