Belajar VAPT #2: Bypass Login Admin Tanpa Password Menggunakan SQL Injection

Overview & Scope Fitur autentikasi/login adalah pintu utama keamanan sebuah aplikasi web. Pada dasarnya, proses login bekerja dengan cara memverifikasi kredensial (username dan password) yang dimasukkan pengguna ke dalam database.

Namun, jika formulir login tidak memiliki sanitasi input yang memadai, celah SQL Injection (SQLi) dapat dimanfaatkan untuk memanipulasi kueri autentikasi tersebut. Hal ini memungkinkan penyerang (attacker) untuk melakukan Authentication Bypass — yaitu masuk ke dalam sistem atau akun hak akses tinggi (seperti administrator) tanpa perlu mengetahui kata sandi (password) yang valid.

a. Target Halaman login PortSwigger Web Security Academy (Lab: SQL injection vulnerability allowing login bypass).

b. Fokus Pengujian Parameter username pada formulir login (/login).

c. Dampak Kerentanan Authentication Bypass/Pengambilalihan akun berhak akses tinggi (Account Takeover).

Reconnaissance Tahap awal dimulai dengan mengeksplorasi alur kerja formulir login pada aplikasi target. Saat mencoba melakukan login menggunakan kredensial acak, aplikasi mengirimkan request HTTP POST ke server:

POST /login HTTP/2

Dengan parameter pada bagian request body:

username=test&password=test

Secara umum, logika kueri SQL di balik layar (backend) yang digunakan untuk memverifikasi login tampak seperti ini:

SELECT * FROM users WHERE username = 'INPUT_USER' AND password = 'INPUT_PASSWORD'

Kueri di atas mengharuskan dua kondisi terpenuhi secara bersamaan:

a. Username yang dimasukkan harus ada di database.

b. Password yang dimasukkan harus cocok dengan username tersebut.

Vulnerability Identification Untuk menguji keberadaan celah SQLi pada mekanisme login, saya mencegat (intercept) lalu lintas request POST login menggunakan Burp Suite dan menyisipkan karakter petik satu (') pada parameter username. Input yang diuji:

username=admin'

Hasilnya, server merespons dengan indikasi kesalahan sintaks kueri (Internal Server Error). Ini menandakan bahwa karakter petik satu berhasil lolos tanpa disanitasi dan mematahkan pembatas string (string literal) kueri SQL asli di backend. Kondisi ini mengonfirmasi bahwa parameter username rentan terhadap SQL Injection karena tidak menggunakan parameterized queries. Hal ini membuka celah bagi attacker untuk menginterupsi logika query SQL asli dan menyisipkan perintah buatan sendiri.

Munculnya 500 Internal Server Error, terutama saat pengguna memasukkan karakter khusus seperti ', ", atau artinya aplikasi mengalami krisis/crash di sisi backend karena menerima input yang tidak ia duga, dan developer tidak membuat mekanisme penanganan error (error handling) yang baik untuk menangani input tersebut.

a. Internal Server Error = Titik Awal Investigasi (Bukan Hasil Akhir) Mendapatkan HTTP 500 berarti kita sudah membentur celah (finding an entry point). Langkah selanjutnya adalah menyesuaikan payload agar perintah dapat dieksekusi dengan sukses tanpa membuat server crash (mengubah status respons dari 500 kembali ke 200 OK dengan hasil eksploitasi).

b. Dampak Tambahan (Verbose Error Message) Kadang, selain HTTP 500, server yang tidak aman juga menampilkan pesan error detail di layar (misal: Uncaught SyntaxError: SQL state [42000] in PostgreSQL…). Ini disebut kerentanan Information Disclosure, yang memberikan petunjuk gratis kepada pentester/attacker tentang jenis database dan struktur kueri yang digunakan backend.

Exploitation (PoC) Setelah mengonfirmasi titik celahnya, langkah selanjutnya adalah membypass pemeriksaan password dan langsung login.

Langkah Eksekusi:

a. Tangkap request HTTP POST saat menekan tombol login di Burp Suite Proxy.

b. Kirim request tersebut ke Burp Suite Repeater untuk eksperimen payload.

c. Modifikasi nilai parameter username menjadi:

admin' OR 1=1 —

Parameter _password_ dapat diisi teks acak atau dibiarkan kosong lalu kirim request.

Analisis Payload: Dengan memasukkan ' OR 1=1 — , struktur query di backend berubah menjadi:

SELECT * FROM users WHERE username = '' OR 1=1 — ' AND password = 'test'

· Karakter ' mematahkan pembatas string username.

· Kondisi OR 1=1 mengevaluasi seluruh baris pada tabel users menjadi BENAR (True), tanpa perlu mengetahui nama username yang spesifik.

· Karakter — mematikan instruksi validasi kata sandi di belakangnya.

Hasil (Result): Server merespons dengan status 302 Found (Redirect) dan memberikan session cookie baru. Halaman web berhasil diperbarui dengan status terautentikasi sebagai administrator, dan lab dinyatakan Solved.

Remediation Kerentanan Authentication Bypass berbasis SQL Injection merupakan salah satu celah paling kritis karena memberikan akses kontrol penuh kepada attacker. Langkah perbaikan yang wajib diterapkan oleh tim pengembang meliputi:

a. Gunakan Prepared Statements (Parameterized Queries) Ini adalah solusi utama dan paling efektif. Jangan pernah menggabungkan input pengguna secara langsung (string concatenation) ke dalam query SQL. Gunakan placeholder agar database memperlakukan input pengguna murni sebagai data, bukan perintah kueri yang dapat dieksekusi.

b. Gunakan Framework ORM / Hashing Safe Engine Sangat disarankan memakai ORM modern yang secara default sudah menangani pengamanan kueri SQL. Selain itu, verifikasi kata sandi idealnya menggunakan fungsi hashing aman (seperti bcrypt atau Argon2) alih-alih pembandingan string SQL secara langsung.

c. Batasi Informasi Error (Disable Verbose Error) Pastikan backend tidak menampilkan detail kesalahan kueri database ke sisi pengguna untuk mencegah attacker melakukan reconnaissance pada struktur database.