Havij dan Era Lama SQL Injection: Pelajaran Penting untuk Keamanan Aplikasi Web

SQL Injection pernah menjadi salah satu celah keamanan aplikasi web yang paling sering ditemukan. Pada era ketika validasi input masih lemah dan banyak aplikasi dibangun dengan query SQL yang dirangkai langsung dari input pengguna, tools seperti Havij cukup populer digunakan untuk mengidentifikasi indikasi kerentanan SQL Injection.

Artikel ini membahas Havij dari sudut pandang historis dan defensif: memahami mengapa celah ini dulu banyak terjadi, dampaknya bagi bisnis, serta bagaimana developer modern dapat mencegahnya.

Pengujian keamanan hanya boleh dilakukan pada sistem milik sendiri atau sistem yang telah memberikan izin tertulis. Menguji website publik tanpa izin dapat melanggar hukum dan mengganggu layanan.

Apa Itu Havij?

Havij adalah tool otomatis yang dahulu dikenal untuk membantu menguji kemungkinan SQL Injection pada aplikasi web. Pada masanya, tool seperti ini menarik perhatian karena dapat mengotomatisasi sejumlah proses pemeriksaan yang sebelumnya dilakukan secara manual.

Secara konsep, Havij mencoba melihat apakah parameter yang dikirimkan ke aplikasi web diproses secara tidak aman oleh database. Jika aplikasi membangun query SQL langsung dari input pengguna tanpa perlindungan yang benar, input tersebut berpotensi mengubah logika query.

Masalah utamanya bukan pada tool-nya, melainkan pada pola coding aplikasi yang rentan.

Mengapa SQL Injection Dulu Sangat Umum?

Banyak aplikasi web lama menggunakan pola query seperti berikut:

String sql = "SELECT * FROM users WHERE username = '" + username + "'";

Kode tersebut terlihat sederhana, tetapi berbahaya. Nilai username berasal dari pengguna dan langsung digabungkan ke dalam query SQL. Jika input tidak divalidasi dan query tidak menggunakan parameter binding, penyerang dapat mencoba memasukkan karakter atau struktur SQL yang mengubah arti query.

Kesalahan umum yang membuat SQL Injection mudah muncul antara lain:

• Menggabungkan input pengguna langsung ke query SQL.
• Tidak menggunakan prepared statement atau parameterized query.
• Memberikan hak akses database terlalu besar kepada aplikasi.
• Menampilkan pesan error database secara langsung ke pengguna.
• Tidak melakukan validasi input pada parameter URL, form, API, maupun header tertentu.
• Menggunakan framework atau library lama yang tidak lagi mendapat pembaruan keamanan.

Dampak SQL Injection bagi Bisnis

SQL Injection bukan hanya masalah teknis. Dampaknya dapat mengenai operasional, reputasi, hingga kepatuhan perusahaan.

Jika berhasil dieksploitasi, celah ini dapat menyebabkan:

• Data pelanggan bocor, termasuk nama, email, nomor telepon, atau alamat.
• Akun administrator diambil alih.
• Data transaksi berubah atau terhapus.
• Informasi internal perusahaan terekspos.
• Layanan aplikasi terganggu.
• Perusahaan menghadapi risiko hukum dan kehilangan kepercayaan pelanggan.

Pada sistem yang menyimpan data sensitif seperti tiket pelanggan, data keuangan, data kesehatan, atau dokumen internal, dampaknya bisa jauh lebih serius.

Pola Rentan yang Harus Dihindari

Berikut contoh pola yang tidak aman:

String sql = "SELECT * FROM ticket WHERE ticket_code = '" + ticketCode + "'";
Statement statement = connection.createStatement();
ResultSet result = statement.executeQuery(sql);

Masalahnya adalah ticketCode langsung masuk ke dalam query. Developer tidak dapat menjamin seluruh input pengguna selalu aman hanya dengan melakukan filter karakter tertentu.

Pendekatan seperti mengganti tanda kutip atau memblokir beberapa kata kunci SQL juga tidak cukup kuat. Pola blacklist mudah terlewati dan sering menimbulkan celah baru.

Cara Aman: Prepared Statement

Gunakan prepared statement atau parameterized query agar nilai input diperlakukan sebagai data, bukan bagian dari struktur SQL.

Contoh Java JDBC:

String sql = "SELECT * FROM ticket WHERE ticket_code = ?";

PreparedStatement statement = connection.prepareStatement(sql);
statement.setString(1, ticketCode);

ResultSet result = statement.executeQuery();

Dengan pendekatan ini, database membedakan struktur query dan nilai parameter. Input pengguna tidak dapat dengan mudah mengubah logika SQL.

Untuk operasi insert:

String sql = """
    INSERT INTO ticket (ticket_code, subject, created_at)
    VALUES (?, ?, NOW())
    """;

PreparedStatement statement = connection.prepareStatement(sql);
statement.setString(1, ticketCode);
statement.setString(2, subject);

statement.executeUpdate();

Jika Menggunakan JPA atau Hibernate

Pada aplikasi Spring Boot, developer sering memakai JPA atau Hibernate. Framework ini membantu mengurangi risiko SQL Injection, tetapi bukan berarti aplikasi otomatis aman.

Contoh aman dengan JPQL parameter:

@Query("SELECT t FROM Ticket t WHERE t.ticketCode = :ticketCode")
Optional<Ticket> findByTicketCode(@Param("ticketCode") String ticketCode);

Contoh aman menggunakan repository convention:

Optional<Ticket> findByTicketCode(String ticketCode);

Tetap berhati-hati jika menggunakan native query. Pastikan parameter tidak dirangkai langsung sebagai string.

@Query(
    value = "SELECT * FROM ticket WHERE ticket_code = :ticketCode",
    nativeQuery = true
)
Ticket findTicket(@Param("ticketCode") String ticketCode);

Lapisan Perlindungan yang Perlu Diterapkan

Prepared statement adalah fondasi, tetapi keamanan sebaiknya tidak hanya bergantung pada satu lapisan.

Prinsip Least Privilege pada Database

Aplikasi web tidak seharusnya terhubung ke database menggunakan akun administrator seperti root, sa, atau akun superuser PostgreSQL.

Buat akun database khusus aplikasi dengan izin seperlunya. Misalnya, aplikasi ticketing hanya membutuhkan akses SELECT, INSERT, dan UPDATE pada tabel tertentu. Jika akun aplikasi tidak memiliki izin menghapus seluruh database atau mengakses tabel sensitif lain, dampak ketika terjadi insiden dapat dikurangi.

Contoh konsep pembagian akses:

• Aplikasi publik: akses terbatas ke tabel dan fungsi yang diperlukan.
• Worker atau service internal: akses khusus sesuai tugas.
• Administrator database: hanya digunakan untuk pekerjaan administrasi.
• Reporting: idealnya menggunakan akun read-only.

Pentingnya Secure Coding

Havij dan berbagai tool keamanan dari era lama mengingatkan bahwa celah besar sering berasal dari kode yang tampak sederhana. Satu query SQL yang dirangkai langsung dari input pengguna dapat membuka risiko kebocoran data dalam skala besar.

Developer modern perlu menjadikan keamanan sebagai bagian dari proses pengembangan, bukan pekerjaan tambahan setelah aplikasi selesai dibuat. Code review, dependency scanning, penetration test berizin, dan audit log sebaiknya masuk ke siklus pengembangan aplikasi.

Kesimpulan

Havij merupakan bagian dari sejarah populer SQL Injection, terutama pada masa ketika banyak aplikasi web belum menerapkan secure coding secara konsisten. Pelajaran utamanya tetap relevan hingga sekarang: jangan pernah menggabungkan input pengguna langsung ke query SQL.

Gunakan prepared statement, terapkan validasi input, batasi hak akses database, dan lakukan pengujian keamanan secara legal pada lingkungan yang diizinkan. Keamanan aplikasi bukan hanya tentang menutup celah saat ditemukan, tetapi membangun sistem agar celah tersebut tidak muncul sejak awal.