PortSwigger Lab: SQL Injection #6 — SQL injection UNION attack, finding a column containing text

Di lab sebelumnya, kita sudah berhasil memetakan jumlah kolom dalam sebuah query. Maka, pertanyaan selanjutnya pun dimulai: Bagaimana kita tahu kolom mana yang bisa kita gunakan untuk mengekstrak data sensitif?

Di lab ini, kita akan mempraktekkan salah satu pilar krusial dalam arsitektur database, yaitu Data Type Compatibility (Keselarasan Tipe Data), dan bagaimana memanfaatkannya untuk meluncurkan serangan yang valid.

Pertama-tama, selalu, meskipun di lab-lab sebelumnya sudah saya singgung. Tapi saya akan tetap memberikan penjelasan. Lagi dan lagi. Recall. Bagi saya, kerangka berpikir dan alasan dibalik sebuah metode serangan pasti akan berbeda-beda di kasus nyata. Tapi, logic di baliknya selalu sama.

Nah, mari kita mulai.

Sebelum meluncurkan payload, kita harus memahami batasan kaku yang dimiliki oleh database SQL.

Saat kita menggunakan operator UNION, kita sedang memaksa database untuk menggabungkan hasil dari dua perintah SELECT yang berbeda (Query Asli Aplikasi + Query Palsu Kita) ke dalam satu tabel baris yang sama. Agar penggabungan ini berhasil tanpa memicu crash pada sistem, database menerapkan dua aturan mutlak:

• Jumlah kolom dari kedua query harus sama persis.
• Tipe data pada setiap kolom yang digabungkan harus kompatibel (searah secara berurutan).

Kebanyakan data sensitif yang ingin kita curi (seperti username dan password) disimpan dalam bentuk teks/string (VARCHAR, TEXT, dll). Jika query asli aplikasi pada Kolom 1 bertipe data Angka (Integer), dan kita memaksa memasukkan teks tiruan seperti 'a', database akan langsung menolak dan melemparkan eror: "Conversion failed when converting the varchar value 'a' to data type int."

Kita harus melakukan probing (pengujian) satu per satu pada setiap kolom yang ada untuk menemukan kolom mana saja yang ramah terhadap tipe data string.

Kita akan membagi proses pengujian ini ke dalam tiga fase terstruktur: Pemetaan Kolom, ****Probing, dan Eksekusi Target.

Di fase pertama, langkah yang harus kita ambil adalah Pemetaan Kolom. Kita harus menemukan jumlah kolom yang dikembalikan oleh query asli. Langkah ini sudah dilakukan di lab sebelumnya.

Kita manfaatkan nilai NULL, karena NULL sifatnya universal dan bisa masuk ke tipe data apa pun (baik angka maupun teks) tanpa memicu eror ketidakcocokan tipe data.

Masukkan payload UNION SELECT yang berisi NULL secara bertahap pada parameter filter kategori produk:

• ' UNION SELECT NULL-- (Internal Server Error)
• ' UNION SELECT NULL, NULL-- (Internal Server Error)
• ' UNION SELECT NULL, NULL, NULL-- (Halaman Terbuka)

Karena halaman web terbuka normal pada percobaan ketiga, kita mendapatkan fakta valid bahwa query asli memiliki 3 buah kolom.

Di sini fase kedua pun dilakukan, yaitu Probing (pengujian).

Setelah mengunci angka 3 sebagai jumlah kolom, kita akan menguji kelayakan tipe data string pada masing-masing kolom secara bergiliran. Kita akan mengganti salah satu nilai NULL dengan karakter string tiruan, yaitu huruf 'a'.

• ' UNION SELECT 'a', NULL, NULL-- (Internal Server Error)
• ' UNION SELECT NULL, 'a', NULL-- (Halaman Terbuka)
• ' UNION SELECT NULL, NULL, 'a'-- (Internal Server Error)

Dari sini kita tahu, bahwa dari ketiga kolom, kolom kedua lah yang merupakan tipe data string:

Setelah mendapatkan di kolom mana tipe data string ditemukan, kita masuk fase ketiga, yaitu Eksekusi Nilai Target.

Lab PortSwigger ini memberikan sebuah nilai acak unik (dalam kasus saya 'hFPFCv') yang wajib kita tampilkan di layar untuk menyelesaikan tantangan. Karena dari Fase 2 kita tahu bahwa kolom kedua adalah pintu masuk yang valid untuk data string, kita cukup mengganti huruf 'a' dengan string acak yang diberikan oleh lab.

Payload: ' UNION SELECT NULL, 'hFPFCv', NULL--