Setiap kali Anda mengetik nama pengguna dan kata sandi di sebuah website, lalu menekan tombol masuk, ada satu hal yang terjadi di balik layar: aplikasi menyusun sebuah perintah untuk database, menanyakan "adakah pengguna dengan nama dan kata sandi ini?". Perintah itu ditulis dalam bahasa khusus bernama SQL (Structured Query Language), bahasa yang dipakai hampir semua aplikasi web untuk berbicara dengan database.
Masalahnya muncul ketika aplikasi menyusun perintah tersebut dengan cara yang ceroboh — yaitu menggabungkan apa yang Anda ketik langsung ke dalam perintahnya, tanpa memeriksa apakah yang Anda ketik itu benar-benar sebuah nama, atau justru perintah tersembunyi. Di titik inilah SQL injection bekerja. SQL injection adalah celah keamanan yang membuat seorang penyerang bisa menyelipkan perintah SQL miliknya sendiri lewat kolom input biasa, lalu membajak percakapan antara aplikasi dan database. Artikel ini membahas apa itu SQL injection, bagaimana cara kerjanya secara konkret, contoh nyatanya, hingga cara mencegahnya.
Apa Itu SQL Injection?
SQL injection (sering disingkat SQLi) adalah jenis serangan yang memanfaatkan celah pada aplikasi web untuk ikut campur dalam perintah SQL yang dikirim aplikasi ke database. Kata "injection" berarti "menyuntikkan" — penyerang menyuntikkan potongan perintah SQL ke tempat yang seharusnya hanya berisi data biasa, seperti kolom pencarian, form login, atau bahkan alamat URL.
Satu hal penting yang perlu diluruskan sejak awal: celah ini ada pada aplikasinya, bukan pada database-nya. Database seperti MySQL bekerja persis seperti yang diperintahkan. Jika aplikasi mengirim perintah berbahaya karena tertipu oleh input pengguna, database hanya menjalankan perintah itu tanpa tahu bahwa ia sedang dimanfaatkan. Jadi akar masalahnya adalah cara aplikasi memperlakukan input dari pengguna, bukan kelemahan pada sistem database itu sendiri.
Meskipun tergolong serangan lama, SQL injection masih sangat relevan. Dalam daftar OWASP Top 10 tahun 2021 — acuan risiko keamanan aplikasi web yang paling banyak dirujuk — kategori Injection (yang mencakup SQL injection) menempati peringkat ketiga. Dari data yang dikumpulkan OWASP, 94% aplikasi yang diuji ternyata memiliki bentuk kelemahan injection, dengan ratusan ribu kejadian tercatat. Angka ini menunjukkan bahwa celah yang secara teori mudah ditutup ternyata masih tersebar luas di lapangan.
Bagaimana Cara Kerja SQL Injection?
Cara paling jelas memahami SQL injection adalah dengan melihat langsung apa yang terjadi pada sebuah query. Bayangkan sebuah form login sederhana. Saat Anda memasukkan nama pengguna dan kata sandi, aplikasi menyusun perintah SQL kira-kira seperti ini:
SELECT * FROM users WHERE username = 'budi' AND password = 'rahasia123';Perintah di atas berarti: "ambil data pengguna yang nama penggunanya budi dan kata sandinya rahasia123". Jika ada baris yang cocok, berarti login berhasil. Sampai di sini semuanya normal.
Persoalan muncul karena bagian 'budi' dan 'rahasia123' tadi berasal langsung dari apa yang diketik pengguna. Sekarang bayangkan seorang penyerang tidak mengetik nama pengguna biasa, melainkan mengetik teks berikut di kolom nama pengguna:
' OR 1=1--Karena aplikasi menggabungkan input itu apa adanya, perintah yang terkirim ke database berubah menjadi:
SELECT * FROM users WHERE username = '' OR 1=1--' AND password = '';Perhatikan perubahannya. Tanda kutip di awal menutup lebih cepat bagian nama pengguna, lalu OR 1=1 menambahkan kondisi baru yang selalu benar (satu memang selalu sama dengan satu). Dua tanda hubung -- adalah penanda komentar dalam SQL, yang membuat database mengabaikan sisa perintah setelahnya — termasuk pengecekan kata sandi. Hasilnya, database mengembalikan semua baris di tabel pengguna, dan aplikasi menganggap login berhasil tanpa kata sandi yang benar.
Inti dari serangan ini terletak pada satu kesalahan mendasar: database tidak bisa membedakan mana bagian perintah yang ditulis oleh programmer dan mana yang diselipkan oleh pengguna. Keduanya tercampur menjadi satu teks. Penyerang memanfaatkan celah ini untuk menyisipkan payload (potongan kode berbahaya) yang mengubah makna perintah aslinya.
Diagram perbandingan query normal dan query disusupi dengan SQL injection.
Contoh SQL Injection yang Umum
Setelah memahami mekanismenya, mari lihat beberapa contoh nyata bagaimana celah ini dimanfaatkan. Contoh-contoh di bawah disajikan untuk tujuan edukasi dan pertahanan — memahami cara serangan bekerja adalah langkah pertama untuk menutupnya.
Membobol halaman login. Ini yang paling klasik. Dengan memasukkan administrator'-- di kolom nama pengguna, penyerang membuat query berhenti tepat setelah nama pengguna dan mengabaikan pengecekan kata sandi. Jika akun administrator memang ada, penyerang bisa masuk sebagai administrator tanpa tahu kata sandinya sama sekali.
Membocorkan data yang tersembunyi. Pada halaman yang menampilkan daftar produk berdasarkan kategori, penyerang bisa mengubah parameter kategori menjadi ' OR 1=1--. Kondisi yang selalu benar tadi membuat database mengembalikan seluruh isi tabel, termasuk produk yang seharusnya disembunyikan atau belum dipublikasikan.
Mengambil data dari tabel lain (UNION). Teknik yang lebih lanjut menggunakan kata kunci UNION untuk menempelkan hasil dari query lain. Sebagai gambaran, payload seperti ' UNION SELECT username, password FROM users-- memaksa database menggabungkan daftar nama pengguna dan kata sandi ke dalam hasil yang seharusnya hanya menampilkan produk. Dari sini, isi tabel sensitif bisa ikut tampil di halaman.
Yang perlu Anda catat, titik masuk serangan tidak terbatas pada form login. Celah bisa muncul di mana saja input pengguna dirangkai ke dalam query: kolom pencarian, parameter di URL, filter urutan data, bahkan data yang dikirim saat menyimpan formulir. Selama input tidak diperlakukan dengan aman, semua lokasi itu berpotensi menjadi pintu masuk.
Jenis-Jenis SQL Injection
Tidak semua serangan SQL injection terlihat langsung hasilnya. Berdasarkan cara penyerang memperoleh informasi, serangan ini dikelompokkan menjadi beberapa jenis.
-
In-band SQL injection: Jenis paling umum dan paling mudah dilakukan. Penyerang mengirim perintah dan menerima hasilnya lewat jalur yang sama — yaitu langsung terlihat di halaman web. Termasuk di dalamnya union-based (memakai UNION untuk menarik data tabel lain) dan error-based (memancing pesan error database yang membocorkan struktur tabel).
-
Blind SQL injection: Di sini hasil query tidak ditampilkan di halaman, sehingga penyerang harus menebak lewat perilaku aplikasi. Pada boolean-based, penyerang mengirim kondisi benar atau salah dan mengamati perbedaan respons halaman. Pada time-based, penyerang menyuruh database menunda respons beberapa detik jika sebuah kondisi benar, lalu mengukur waktu jawaban untuk menyimpulkan isinya. Prosesnya lambat, tapi tetap efektif.
-
Out-of-band SQL injection: Jenis yang lebih jarang, dipakai saat jalur langsung tidak tersedia. Penyerang membuat database mengirim data ke server lain lewat jalur terpisah, misalnya lewat permintaan DNS. Teknik ini bergantung pada fitur tertentu yang aktif di server database.
Perbedaan utama antarjenis ini bukan pada tingkat bahayanya, melainkan pada seberapa mudah penyerang melihat hasil serangannya. Blind SQL injection lebih merepotkan bagi penyerang, tetapi celah yang mendasarinya sama saja berbahayanya.
Diagram tiga jenis SQL injection: In-band, Blind, dan Out-of-band.
Dampak Serangan SQL Injection
Ketika sebuah serangan berhasil, akibatnya bisa menyentuh hampir semua aspek keamanan data. Berdasarkan uraian OWASP, dampaknya dapat dikelompokkan sebagai berikut:
-
Kebocoran data (kerahasiaan): Penyerang bisa membaca data yang seharusnya rahasia — daftar pelanggan, alamat email, kata sandi, hingga data pembayaran. Inilah dampak yang paling sering terjadi.
-
Pembobolan autentikasi: Seperti pada contoh login tadi, penyerang bisa masuk ke sistem tanpa kredensial yang sah, sering kali langsung sebagai administrator.
-
Manipulasi hak akses (otorisasi): Dengan mengubah data di database, penyerang bisa menaikkan level akun miliknya atau membuka pintu untuk serangan lanjutan.
-
Perubahan dan penghapusan data (integritas): Penyerang tidak hanya membaca, tetapi juga bisa mengubah atau menghapus record. Bayangkan seluruh isi tabel transaksi diubah atau dihapus dalam sekejap.
Pada kasus yang lebih parah dan bergantung pada konfigurasi server, celah ini bahkan bisa dimanfaatkan untuk membaca berkas di sistem server database atau menjalankan perintah pada sistem operasi. Skala kerusakannya membuat SQL injection tetap menjadi salah satu ancaman yang paling ditakuti pemilik website.
Cara Mencegah SQL Injection
Kabar baiknya, meski dampaknya besar, SQL injection termasuk celah yang paling bisa dicegah — asalkan penyebab utamanya dipahami. Ingat kembali akar masalahnya: database tidak bisa membedakan mana kode perintah dan mana data dari pengguna. Semua cara pencegahan yang efektif pada dasarnya berusaha memisahkan dua hal itu.
-
Gunakan parameterized query (prepared statement): Ini pertahanan utama dan paling ampuh. Alih-alih menggabungkan input pengguna langsung ke dalam teks query, Anda menyiapkan kerangka query dengan penanda kosong (biasanya tanda
?), lalu menyerahkan nilai input secara terpisah. Dengan cara ini, database sudah tahu lebih dulu mana bagian perintah dan mana data, sehingga apa pun yang diketik pengguna — termasuk' OR 1=1--— hanya diperlakukan sebagai teks biasa, bukan perintah. Celahnya tertutup di akarnya, bukan ditambal di permukaan. -
Validasi input dengan daftar putih (allowlist): Untuk bagian query yang tidak bisa dijadikan parameter, misalnya nama kolom pada pengurutan data, batasi nilai yang diterima hanya pada daftar yang sudah Anda tentukan. Kalau nilai di luar daftar, tolak. Cara ini menutup celah yang tidak tercakup oleh parameterized query.
-
Manfaatkan ORM dengan benar: Banyak framework modern seperti Laravel menyediakan ORM (Object-Relational Mapping) yang secara default sudah memakai parameter binding di balik layar. Selama Anda tidak menulis query mentah secara manual, sebagian besar celah sudah tertutup otomatis.
-
Terapkan prinsip hak akses minimal: Berikan akun database yang dipakai aplikasi hanya izin yang benar-benar diperlukan. Jika akun itu tidak punya izin menghapus tabel, kerusakan dari serangan yang lolos pun ikut terbatas.
-
Tambahkan firewall aplikasi web sebagai lapisan ekstra: Sebuah firewall aplikasi web (WAF) bisa menyaring pola serangan yang umum sebelum sampai ke aplikasi. Namun perlu ditegaskan, ini adalah lapisan tambahan, bukan pengganti perbaikan kode.
Ada satu kesalahpahaman yang perlu diluruskan. Sebagian orang mengira cukup dengan "membersihkan" karakter berbahaya secara manual (menyaring tanda kutip, misalnya) atau memakai stored procedure, celah sudah aman. Kenyataannya, OWASP secara khusus menyatakan bahwa kedua cara ini tidak cukup bila berdiri sendiri. Penyaringan manual mudah terlewat pada satu titik, dan stored procedure pun masih bisa rentan jika di dalamnya query tetap dirangkai dari string. Parameterized query tetap menjadi fondasi yang tidak tergantikan.
Hal yang Perlu Anda Pertimbangkan
Tidak ada satu langkah tunggal yang membuat aplikasi kebal seratus persen. Pengamanan yang baik selalu berlapis, dan tiap lapis punya untung-ruginya masing-masing.
Parameterized query hampir tidak memakan biaya — ia bagian dari cara menulis kode yang benar, bukan tambahan mahal. Karena itu, tidak ada alasan untuk melewatkannya. Sementara itu, firewall aplikasi web memang membantu, tetapi menuntut perawatan: aturannya perlu diperbarui, dan kalau terlalu longgar ia gampang ditembus, kalau terlalu ketat ia bisa memblokir pengguna yang sah. Bergantung hanya pada firewall tanpa memperbaiki kode adalah kesalahan yang umum — ibarat memasang gembok bagus di pintu, tetapi jendelanya dibiarkan terbuka.
Pertimbangan lain adalah kode lama. Banyak website berjalan di atas kode yang ditulis bertahun-tahun lalu, saat praktik keamanan belum seketat sekarang. Memeriksa dan memperbaiki query lama satu per satu memang menyita waktu, tetapi jauh lebih murah dibanding menanggung akibat kebocoran data.
FAQ Seputar SQL Injection
Apakah SQL injection masih relevan saat ini? Ya. Meski tekniknya sudah dikenal sejak lama, celah ini masih menempati peringkat tinggi dalam daftar risiko OWASP Top 10 karena banyak aplikasi masih ditulis dengan cara yang rentan.
Apakah website WordPress bisa terkena SQL injection? Bisa, terutama lewat plugin atau tema pihak ketiga yang menulis query secara tidak aman. Inti WordPress relatif terlindungi, tetapi kerentanan sering datang dari komponen tambahan. Rajin memperbarui plugin dan tema adalah langkah penting.
Apa bedanya SQL injection dengan XSS? Keduanya sama-sama serangan penyisipan (injection), tapi sasarannya berbeda. SQL injection menyasar database di sisi server, sedangkan XSS (Cross-Site Scripting) menyasar browser pengguna lain dengan menyelipkan kode di halaman web.
Apakah memakai ORM otomatis membuat aman? Sebagian besar iya, selama Anda memakainya sesuai cara standar. Tetapi begitu Anda menulis query mentah secara manual di dalam ORM dan menggabungkan input pengguna ke dalamnya, celah SQL injection bisa terbuka kembali.
Kesimpulan
SQL injection adalah celah keamanan yang lahir dari satu kesalahan mendasar: input dari pengguna dipercaya mentah-mentah dan dirangkai langsung menjadi perintah SQL, sehingga database tidak bisa lagi membedakan mana perintah asli dan mana yang diselipkan penyerang. Dari celah sederhana ini, akibatnya bisa meluas hingga kebocoran data, pembobolan login, sampai penghapusan seluruh isi database.
Kunci pencegahannya justru sesederhana penyebabnya: pisahkan data dari kode. Selama Anda konsisten memakai parameterized query, melengkapinya dengan validasi input dan hak akses minimal, sebagian besar risiko sudah tertutup. Firewall dan lapisan lain berguna sebagai pelengkap, tetapi tidak pernah menggantikan kode yang ditulis dengan benar. Semoga artikel ini membantu Anda memahami SQL injection dan langkah-langkah untuk mencegahnya.
