Lewati ke konten
← Semua catatan

WRITE-UP / SQL

Perbaikan SQL injection harus bisa diuji ulang.

Dari query gabungan string ke parameter terikat, lalu uji karakter khusus, otorisasi, dan pilihan sorting secara terpisah.

HEXPLOIT / Catatan edukasi sintetis · 22 Oktober 2026 · 2 mnt baca

Ilustrasi konseptual pemisahan struktur query dan nilai parameter.
Ilustrasi editorial dibuat dengan AI. Bukan bukti pengujian atau insiden nyata.

Materi edukasi sintetis, bukan laporan kerentanan produk. Kode adalah ilustrasi, bukan implementasi siap produksi. Pengujian hanya pada data dan sistem yang kamu kuasai atau diizinkan secara tertulis.

Fixture lokal, data sintetis

Skenario ini memakai direktori pelanggan lokal dengan nama biasa, nama berapostrof, dan beberapa baris dari tenant berbeda. Tidak ada target publik, payload pengambilan data, atau pengujian sistem pihak ketiga. Tujuannya membuktikan input nama tetap diperlakukan sebagai data.

Pisahkan struktur dan nilai

Query yang dibangun dengan menggabungkan input ke teks SQL mencampurkan struktur dan nilai. Gunakan parameter driver untuk nilai. Validasi panjang dan tipe tetap berguna, tetapi bukan pengganti parameterisasi.

pseudocode
sql = "SELECT id, name FROM customers
       WHERE tenant_id = $1 AND name = $2"
rows = db.query(sql, [actor.tenantId, requestedName])
// Placeholder syntax depends on the database driver.

Kolom sorting bukan nilai biasa

Parameter nilai tidak otomatis berlaku untuk nama kolom atau arah sorting. Jika pengguna memilih urutan, petakan pilihan terbatas ke identifier yang ditetapkan pengembang. Jangan menyisipkan nama kolom bebas dari permintaan.

pseudocode
columns = { "name": "name", "recent": "created_at" }
column = columns.get(requestedSort)
if column is absent: return invalidSort()
// Only this developer-controlled column is used in ORDER BY.

Kriteria penerimaan perbaikan

Gunakan nama pelanggan sintetis O’Neil dan string kosong sebagai kasus fungsional. Pastikan query tidak gagal hanya karena tanda baca. Lalu uji tenant lain dengan akun uji kedua: parameterisasi bukan kontrol otorisasi.

  • Input disalurkan sebagai parameter, bukan digabungkan ke SQL.
  • Pilihan sorting tidak dikenal ditolak sebelum query dibuat.
  • Respons error tidak menampilkan query, kredensial, atau stack internal.

Batas kesimpulan

Satu query yang diperbaiki tidak menjamin seluruh aplikasi bebas injection. Inventarisasi jalur query lain, periksa penggunaan ORM/raw query, dan batasi izin akun basis data sesuai kebutuhannya. Lampirkan hasil uji nyata sebelum menyatakan perbaikan selesai pada produk.

Referensi & pembacaan lanjutan

Tulisan ini merupakan sintesis edukasi, bukan salinan atau afiliasi dengan sumber berikut. Gunakan dokumentasi primer untuk keputusan implementasi.