Pernah nggak sih kalian nemuin halaman login web yang UI-nya estetik banget, warnanya ungu pastel gemoy, dan kelihatan super aman? Buat pengguna internet awam, itu ya cuma sekadar kotak biasa buat ngisi username sama password. Tapi percaya deh, di mata pihak yang niatnya emang nyari celah, form sepolos itu bisa aja jadi gerbang utama buat ngeksploitasi seluruh isi database.

Jujur aja nih, sebagai anak Teknik Informatika yang sekarang lagi lumayan pusing ngerjain berbagai tugas coding di semester 4, aku sendiri sering banget keasyikan ngulik tampilan front-end biar cakep atau fokus mikirin logic fiturnya supaya jalan tanpa error. Saking asyiknya ngurusin tampilan dan fitur, bagian security atau keamanan malah sering dinomorduakan. Padahal kalau udah kebobolan, efeknya bisa berabe banget! Nah, salah satu ancaman yang umurnya udah tua tapi entah kenapa masih sering banget memakan korban sampai detik ini adalah SQL Injection.

Lewat artikel ini, aku mau cerita sedikit soal eksperimen iseng tapi serius yang baru aja aku lakuin buat tugas UTS. Kita bakal sama-sama ngebedah gimana sih sebenarnya cara kerja celah SQL Injection itu. Enggak cuma berhenti di cara nyerangnya aja, aku juga bakal share gimana cara kita sebagai calon developer buat nambal celah tersebut, supaya aplikasi web yang kita bangun nanti nggak gampang dijebol orang.

Apa itu SQL injection?

Sebelum masuk ke sesi eksperimen kalian tuh bertanya — tanya ga sih SQL injection tuh sebenernya apaan sih? Yuk kita bahas tipis-tipis dulu soal apa itu SQL Injection (SQLi). Biar gampang bayanginnya, analoginya gini: anggap aja database itu sebuah brankas rahasia, nah form login itu satpam yang jagain pintunya.

Kalau lagi normal, kita ngasih KTP (username dan password) ke satpam. Si satpam bakal ngecek catatannya (ngejalanin perintah SQL), "Eh, KTP ini terdaftar nggak ya di sistem?". Kalau ada, baru deh kita dibolehin masuk.

Nah, kalau SQL Injection beda cerita. Si penyerang ini bukannya ngasih KTP, tapi dia malah ngasih "surat perintah palsu" ke satpam. Bahayanya, si satpam ini kadang terlalu polos (alias sistem web-nya nggak nge-filter input dari user). Alhasil, dia malah nurut aja dan ngejalanin perintah palsu itu.

Nah, karena hal ini juga yang bikin para peretas bisa nge-bypass atau ngakalin logika sistem. Dia bisa aja nyuruh satpam buka brankas tanpa perlu ngecek password sama sekali! Kalau di bahasa teknisnya, SQL Injection itu kejadian kalau aplikasi web kita main "telan mentah-mentah" ketikan dari user terus langsung dimasukin ke query database tanpa disaring dulu. Ngeri kan?

Eksperimen Menembus Sistem (The Attack)

Sekarang masuk ke bagian serunya, yaitu eksperimen langsung! Di sini aku bikin dulu simulasi halaman login yang sederhana — sederhana aja pakai PHP dan database MySQL. Biar nggak kaku, tampilannya aku bikin sedikit imut dengan nuansa ungu pastel yang basic tapi tetap imut. Tapi jangan salah, di balik tampilannya yang imut, form ini sengaja aku buat rentan dengan menuliskan kode query yang langsung mengeksekusi input pengguna tanpa filter (vulnerable code).

Percobaan Pertama: Gagal Menembus Sistem

Awalnya, aku mencoba melakukan injeksi dengan payload klasik: ' OR Ƈ'=Ƈ. Logika dasarnya, karena 1=1 itu nilainya selalu benar (True), seharusnya aku bisa masuk dong? Eh, ternyata gagal dan muncul pesan Username atau Password salah!

Setelah dianalisis, ternyata ini karena adanya hierarki (urutan) eksekusi logika di dalam SQL. Operator AND (yang bertugas mengecek password) selalu dieksekusi lebih dulu daripada OR. Jadi, meskipun bagian depannya True, sistem tetap menolak karena password yang aku masukkan salah.

None

Percobaan Kedua: Sukses Mengeksploitasi Celah

Karena percobaan pertama gagal, aku mengubah strategi. Bagaimana caranya agar sistem tidak perlu mengecek password sama sekali? Jawabannya adalah menggunakan simbol komentar di MySQL, yaitu tanda pagar (#).

Aku kembali mencoba login dengan memasukkan input manipulatif berikut di kolom username: ' OR Ƈ'=Ƈ' # Dan untuk kolom password, aku isi asal-asalan saja.

None

Jeng jeng! Aku berhasil masuk ke dalam sistem! Ternyata, tanda pagar (#) tadi berfungsi memotong perintah SQL. Sistem dipaksa membaca logika Ƈ'=Ƈ' yang bernilai True, dan mengabaikan sama sekali perintah untuk mengecek password di belakangnya. Lewat eksperimen ini, terbukti betapa fatalnya sebuah sistem jika kolom input tidak diamankan dengan benar.

Menambal Celah Biar Aman (The Fix)

Setelah sukses jadi "hacker" dadakan dan berhasil menembus sistem sendiri, sekarang saatnya kita balik ke jati diri asli sebagai developer. Gimana sih caranya nambal celah SQL Injection ini biar form login kita nggak gampang dibobol lagi?

Solusi paling ampuh dan wajib banget dipelajari sama mahasiswa IT (terutama yang ngoding pakai PHP) adalah menggunakan teknik Prepared Statements.

Kalau sebelumnya sistem kita main "telan mentah-mentah" input dari user, dengan Prepared Statements, kita memisahkan antara struktur perintah SQL dengan data yang diinputkan. Ibaratnya, kita ngasih tahu si satpam penjaga brankas: "Pak, nanti bakal ada orang yang ngasih nama, tapi ingat ya, apapun yang dia tulis itu cuma sekadar NAMA, jangan pernah dianggap sebagai perintah!"

Di kode PHP yang baru, aku mengubah query rentan tadi menjadi seperti ini:

// SECURE CODE: Menggunakan Prepared Statements untuk mencegah SQL Injection
$query = "SELECT * FROM users WHERE username = ? AND password = ?";
    
// Siapkan statement
$stmt = mysqli_prepare($koneksi, $query);
    
// Hubungkan parameter input (s = string)
mysqli_stmt_bind_param($stmt, "ss", $username, $password);
    
// Eksekusi statement
mysqli_stmt_execute($stmt);

Dengan kode di atas, sistem akan menganggap tanda tanya ? sebagai tempat kosong yang murni berisi teks. Jadi, pas aku coba masukin payload jahat ' OR Ƈ'=Ƈ' # lagi, sistem bakal ngebaca itu murni sebagai username yang aneh, bukan sebagai perintah SQL.

None

Hasilnya? Serangan berhasil ditangkis! Sistem menolak akses masuk karena tidak ada user di dalam database yang username-nya bernama ' OR Ƈ'=Ƈ' #. Aman deh!

Dari eksperimen singkat ini, ada satu pelajaran berharga yang bisa kita ambil: bikin website dengan tampilan yang estetik dan gemoy itu memang penting buat narik perhatian user, tapi keamanan sistem adalah harga mati.

Mengecek dan memfilter input dari pengguna adalah langkah dasar yang nggak boleh dilewatin. Buat teman-teman developer atau sesama mahasiswa yang lagi bikin project web, yuk mulai biasakan nulis kode yang aman dari sekarang. Jangan sampai aplikasi capek-capek kita bikin malah jadi bulan-bulanan peretas cuma gara-gara kita malas pakai Prepared Statements.

Referensi:

OWASP Foundation. (2021). A03:2021-Injection. OWASP Top 10:2021. Diakses pada 30 April 2026, dari https://owasp.org/Top10/A03_2021-Injection/

OWASP Foundation. (n.d.). SQL Injection Prevention Cheat Sheet. OWASP Cheat Sheet Series. Diakses pada 30 April 2026, dari https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html

PortSwigger. (n.d.). SQL injection. Web Security Academy. Diakses pada 30 April 2026, dari https://portswigger.net/web-security/sql-injection

The PHP Group. (n.d.). Prepared Statements. PHP Manual. Diakses pada 30 April 2026, dari https://www.php.net/manual/en/mysqli.quickstart.prepared-statements.php