#05 SQLMap Cheat Sheet: SQL Injection Testing untuk Security Assessment

SQL injection punya reputasi seperti lagu lama yang entah kenapa masih sering diputar. Teknologinya berubah, framework makin modern, ORM makin populer, tetapi satu kebiasaan buruk tetap bisa membuka pintu: mencampurkan input yang tidak dipercaya ke query database secara tidak aman.

Di artikel #05 Red Team Cheat Sheet Series ini kita membahas sqlmap, tool open-source yang mengotomatisasi proses deteksi dan validasi SQL injection. Fokusnya bukan "bagaimana mengambil sebanyak mungkin data", melainkan bagaimana memakai automation secara terukur untuk memvalidasi temuan pada lab atau security assessment yang memiliki authorization, mengumpulkan evidence secukupnya, lalu menerjemahkannya menjadi perbaikan yang benar.

Scope dulu, terminal belakangan. Contoh di artikel ini menggunakan aplikasi lab lokal. Jangan menjalankan sqlmap terhadap aplikasi yang tidak Anda miliki atau tidak secara eksplisit tercantum dalam Rules of Engagement.

SQL Injection dalam Satu Menit

Bayangkan aplikasi menerima parameter id lalu membangun query dengan string concatenation:

SELECT name, email FROM users WHERE id = '<INPUT_USER>';

Masalah muncul ketika aplikasi memperlakukan input user sebagai bagian dari struktur SQL, bukan sebagai data biasa. Input yang dirancang khusus dapat mengubah maksud query.

Jadi akar masalahnya bukan "karakter aneh". Akar masalahnya adalah batas antara data dan instruction menjadi kabur.

Itulah mengapa solusi utamanya bukan membuat blacklist karakter yang makin panjang. Defense yang jauh lebih kuat adalah prepared statements / parameterized queries, ditambah least privilege dan validation yang sesuai konteks.

Lalu sqlmap Itu Apa?

sqlmap adalah penetration-testing tool yang mengotomatisasi detection dan exploitation workflow untuk SQL injection. Ia dapat menerima target URL atau raw HTTP request, melakukan fingerprint terhadap DBMS, menguji berbagai injection technique, dan menyediakan banyak opsi lanjutan.

Kemampuan tool ini luas. Justru karena itu kita perlu disiplin.

Dalam assessment profesional, pertanyaan yang sehat bukan:

"Seberapa jauh sqlmap bisa masuk?"

Melainkan:

"Evidence minimum apa yang cukup untuk membuktikan vulnerability dan impact-nya?"

Kalau satu parameter sudah tervalidasi injectable, tidak ada medali tambahan karena kita membuat production database bekerja lembur.

Setup Lab

Gunakan vulnerable application yang memang dibuat untuk latihan, misalnya DVWA, WebGoat, Juice Shop untuk topik yang relevan, atau aplikasi lab buatan sendiri.

Contoh kita memakai host lokal hipotetis:

Attacker : 10.10.10.5
Web Lab  : 10.10.10.20
URL      : http://10.10.10.20/item.php?id=1

Pastikan VM berada pada network terisolasi dan buat snapshot sebelum eksperimen.

Untuk sqlmap, cara paling aman mendapatkan versi terbaru adalah mengikuti repository resmi. Setelah tersedia:

python sqlmap.py -h

Untuk seluruh opsi:

python sqlmap.py -hh

Jangan mulai dengan menghafal ratusan switch. Kita hanya butuh beberapa opsi inti untuk memahami workflow.

1. Mulai dari Request yang Sudah Dipahami

Misalnya lab memiliki URL:

http://10.10.10.20/item.php?id=1

Sebelum automation, buka endpoint tersebut secara normal. Pahami:

• parameter apa yang dikirim;
• response normal seperti apa;
• apakah authentication diperlukan;
• apakah request mengubah data;
• apakah endpoint sensitif terhadap volume request.

Baru setelah itu lakukan detection terbatas:

python sqlmap.py -u "http://10.10.10.20/item.php?id=1" -p id

-u menentukan target URL dan -p id memperjelas parameter yang memang masuk scope pengujian.

Kenapa saya suka menyebut -p secara eksplisit? Karena automation yang tahu persis apa yang diuji biasanya lebih baik daripada automation yang disuruh "coba semuanya dan semoga server tetap bahagia".

2. Raw HTTP Request: Lebih Realistis untuk Aplikasi Modern

Aplikasi nyata sering memakai POST, JSON, cookie, custom header, CSRF token, atau authentication flow. Daripada memindahkan semuanya menjadi command panjang, simpan request yang sudah diotorisasi ke file, misalnya request.txt.

Kemudian:

python sqlmap.py -r request.txt -p id

Opsi -r meminta sqlmap membaca raw HTTP request dari file.

Workflow ini berguna ketika request berasal dari proxy seperti Burp Suite dan kita ingin mempertahankan bentuk request sedekat mungkin dengan aplikasi sebenarnya.

Tetap review file tersebut. Jangan menyimpan token production sembarangan ke repository, ticket publik, atau folder yang dibackup tanpa proteksi.

3. Verbosity: Ketika Kita Ingin Tahu Apa yang Terjadi

Jika hasil terasa aneh, naikkan verbosity secukupnya:

python sqlmap.py -u "http://10.10.10.20/item.php?id=1" -p id -v 3

sqlmap mendukung beberapa level verbosity. Gunanya bukan supaya terminal terlihat lebih hacker-ish, melainkan membantu memahami request, response, dan proses detection.

Kalau tool memberi hasil yang tidak masuk akal, jangan langsung menaikkan semua opsi. Lihat dulu apa yang sebenarnya terjadi.

4. --level: Lebih Tinggi Bukan Selalu Lebih Pintar

sqlmap memiliki opsi --level yang mengatur seberapa luas test yang dilakukan. Default-nya rendah dan level lebih tinggi dapat mencoba lebih banyak payload/boundary serta titik input tambahan.

Contoh di lab:

python sqlmap.py -u "http://10.10.10.20/item.php?id=1" -p id --level=2

Semakin tinggi level, semakin banyak request yang mungkin dihasilkan.

Jadi jangan berpikir:

"Level 5 pasti paling pro."

Tidak. Kadang itu hanya berarti lebih banyak traffic untuk menjawab pertanyaan yang sebenarnya sudah terjawab di level 1.

Pada production assessment, peningkatan intensitas harus mengikuti RoE dan kondisi aplikasi.

5. --risk: Namanya Sudah Memberi Peringatan

sqlmap juga menyediakan pengaturan --risk untuk mengontrol kelas test tertentu.

Prinsip praktisnya sederhana: jangan menaikkan risk tanpa memahami konsekuensi payload yang akan diuji.

Untuk seri ini kita tidak menjadikan --risk=3 sebagai command default. Tujuan kita adalah validasi yang terukur, bukan melihat seberapa cepat monitoring team menelepon.

6. --batch: Berguna untuk Lab dan Automation Terkontrol

Dalam lab, kita dapat menghindari prompt interaktif:

python sqlmap.py -u "http://10.10.10.20/item.php?id=1" -p id --batch

--batch memakai jawaban default untuk pertanyaan interaktif.

Nyaman untuk workflow berulang, tetapi ada trade-off: kita kehilangan kesempatan berhenti dan berpikir pada setiap prompt.

Untuk target sensitif, interaksi manual justru sering bagus. Automation memang cepat. Sayangnya ia juga cepat ketika mengambil keputusan yang salah.

7. Fingerprinting: Identifikasi, Bukan Pesta Data

Setelah injection tervalidasi dalam lab, kita dapat melakukan fingerprint terbatas untuk memahami backend DBMS.

Salah satu informasi yang umum divalidasi adalah banner DBMS pada environment latihan:

python sqlmap.py -u "http://10.10.10.20/item.php?id=1" -p id --banner

Dalam engagement nyata, berhenti dan tanyakan: apakah informasi tersebut memang diperlukan untuk membuktikan impact?

Sering kali jawaban teknis yang dibutuhkan sudah tersedia tanpa melakukan enumerasi data sensitif.

8. Database Enumeration: Hanya Jika Scope Memerlukannya

Di lab, sqlmap dapat menampilkan database yang terlihat oleh account aplikasi:

python sqlmap.py -u "http://10.10.10.20/item.php?id=1" -p id --dbs

Tetapi jangan menganggap ini langkah wajib setelah menemukan SQLi.

Dalam production assessment, enumerasi schema atau data dapat menyentuh informasi sensitif dan menambah impact. Gunakan hanya jika RoE mengizinkan dan evidence tersebut memang dibutuhkan.

Prinsipnya:

prove, document, stop.

Bukan:

prove, dump everything, lalu baru bertanya apakah boleh.

Cheat Sheet SQLMap untuk Lab

# Basic help
python sqlmap.py -h

# Advanced help
python sqlmap.py -hh

# Test parameter tertentu pada lab
python sqlmap.py -u "http://10.10.10.20/item.php?id=1" -p id

# Load raw HTTP request
python sqlmap.py -r request.txt -p id

# Tambah verbosity untuk troubleshooting
python sqlmap.py -u "http://10.10.10.20/item.php?id=1" -p id -v 3

# Detection level yang sedikit lebih luas
python sqlmap.py -u "http://10.10.10.20/item.php?id=1" -p id --level=2

# Non-interactive untuk lab terkontrol
python sqlmap.py -u "http://10.10.10.20/item.php?id=1" -p id --batch

# Fingerprint banner DBMS pada lab
python sqlmap.py -u "http://10.10.10.20/item.php?id=1" -p id --banner

# Enumerasi database hanya bila diizinkan/diperlukan
python sqlmap.py -u "http://10.10.10.20/item.php?id=1" -p id --dbs

Perhatikan apa yang tidak ada di cheat sheet ini: command untuk dumping massal data, file-system takeover, atau OS command execution. sqlmap memang memiliki kemampuan yang jauh lebih luas, tetapi artikel dasar security assessment tidak perlu mengubah validasi SQLi menjadi simulasi bencana nasional.

Workflow SQLMap yang Lebih Sehat

Saya lebih menyukai alur seperti ini:

Scope & RoE
    ↓
Capture normal request
    ↓
Manual sanity check
    ↓
Select exact parameter
    ↓
Low-intensity SQLi detection
    ↓
Validate evidence
    ↓
Minimal impact confirmation
    ↓
Detection review
    ↓
Remediation
    ↓
Retest

Tahap 1 — Pahami Request

Jangan memberikan request yang bahkan kita sendiri tidak mengerti kepada automation.

Tahap 2 — Tentukan Injection Point

Gunakan parameter yang memang dicurigai dan termasuk scope.

Tahap 3 — Mulai Rendah

Gunakan default atau level rendah terlebih dahulu.

Tahap 4 — Validasi

Pastikan hasil bukan false positive akibat error page, caching, WAF behavior, atau response dinamis.

Tahap 5 — Ambil Evidence Minimum

Buktikan vulnerability tanpa mengakses data yang tidak diperlukan.

Tahap 6 — Dokumentasikan

Simpan request, parameter, timestamp, response yang relevan, dan kondisi pengujian.

Studi Kasus: Endpoint Produk Lama

Bayangkan aplikasi internal memiliki endpoint:

GET /legacy/product.php?id=42

Aplikasi baru sudah memakai ORM, tetapi endpoint legacy masih membangun SQL menggunakan string concatenation.

Assessment menemukan parameter id berperilaku tidak konsisten ketika menerima input tertentu. Tim kemudian menggunakan sqlmap secara terbatas pada parameter tersebut dan mengonfirmasi bahwa backend memperlakukan sebagian input sebagai SQL syntax.

Temuan yang buruk akan ditulis seperti ini:

SQLMap berhasil. Severity: Critical.

Temuan yang berguna menjelaskan:

• endpoint dan parameter terdampak;
• authentication context;
• teknik validasi yang digunakan;
• evidence minimum;
• DBMS context jika relevan;
• privilege database account;
• potensi data exposure;
• apakah WAF atau monitoring mendeteksi aktivitas;
• root cause pada source code;
• remediation dan hasil retest.

Tool hanyalah bagian kecil dari cerita.

Attack → Evidence → Detection → Hardening

Sekarang kita pakai pola khas seri ini.

Attack / Activity

SQL injection testing menghasilkan serangkaian HTTP request dengan variasi input yang dirancang untuk melihat apakah input memengaruhi struktur query atau perilaku database.

Evidence

Defender mungkin melihat:

• lonjakan request ke parameter yang sama;
• variasi query-string atau body yang tidak biasa;
• database error pada application log;
• response-time anomaly untuk teknik berbasis waktu;
• pola HTTP request berulang dari source yang sama;
• WAF event terkait injection pattern;
• query database yang bentuknya tidak lazim.

Tidak semua evidence akan muncul pada setiap teknik. Dan tidak semua karakter "aneh" berarti serangan.

Detection

Blue Team sebaiknya menggabungkan beberapa data source:

• reverse proxy / web server log;
• WAF telemetry;
• application log;
• database audit log bila tersedia;
• APM;
• EDR pada application server;
• SIEM correlation.

Detection yang hanya mencari satu string payload mudah menghasilkan false positive dan mudah kehilangan variasi lain.

Lebih menarik jika kita mengorelasikan request anomaly + application/database error + source behavior + endpoint sensitivity.

Hardening

Nah, ini bagian terpenting.

Menurut OWASP, defense utama terhadap SQL injection adalah menghindari dynamic query yang dibangun dengan string concatenation dan menggunakan prepared statements / parameterized queries.

Contoh konseptual yang buruk:

query = "SELECT * FROM users WHERE id = '" + input + "'"

Konsep yang benar:

query = "SELECT * FROM users WHERE id = ?"
bind(input)

Nilai user diperlakukan sebagai data, bukan sebagai bagian dari SQL syntax.

Tambahkan defense-in-depth:

• allow-list validation ketika masuk akal;
• least privilege untuk database account;
• jangan gunakan account database dengan privilege administratif untuk aplikasi biasa;
• batasi network exposure database;
• jangan menampilkan detailed database error kepada user;
• logging dan monitoring yang memadai;
• code review dan SAST/DAST sesuai SDLC;
• dependency dan framework lifecycle management.

Kenapa WAF Bukan Obat Utama?

WAF berguna sebagai lapisan tambahan. Tetapi kalau source code masih membangun query dengan concatenation, vulnerability dasarnya tetap ada.

Mengandalkan WAF sebagai satu-satunya solusi SQLi seperti memasang satpam di depan pintu sementara kunci pintunya masih tergantung di luar.

Perbaiki query terlebih dahulu. WAF menjadi defense-in-depth, bukan pengganti secure coding.

Least Privilege: Kalau SQLi Terjadi, Jangan Beri Kunci Gedung

Aplikasi web sering hanya membutuhkan operasi tertentu pada schema tertentu.

Kalau database account aplikasi memiliki privilege berlebihan, impact SQL injection ikut membesar.

Review:

• schema mana yang boleh diakses;
• operasi SELECT/INSERT/UPDATE/DELETE yang benar-benar dibutuhkan;
• apakah account dapat membuat user atau schema;
• apakah account dapat mengakses database lain;
• apakah administrative function tersedia tanpa alasan.

Least privilege tidak menghilangkan SQL injection, tetapi dapat membatasi blast radius.

Best Practices Menggunakan sqlmap dalam Assessment

1. Jangan Mulai dari Automation

Pahami request dan aplikasi terlebih dahulu.

2. Target Parameter yang Jelas

Lebih baik menguji satu parameter yang masuk akal daripada menyemprot semua input tanpa konteks.

3. Mulai dengan Intensitas Rendah

Naikkan --level hanya jika memang dibutuhkan.

4. Hati-hati dengan Endpoint yang Mengubah State

Request POST tertentu bisa membuat order, menghapus data, mengirim email, atau menjalankan workflow bisnis. Automation dapat mengulang request berkali-kali.

5. Lindungi Credential dan Session Token

Raw request adalah evidence sensitif. Perlakukan seperti credential-bearing artifact.

6. Catat Timestamp

Membantu Blue Team mengorelasikan pengujian dengan log.

7. Jangan Mengambil Data Lebih Banyak dari yang Dibutuhkan

Security assessment bukan lomba siapa paling besar file dump-nya.

8. Retest Setelah Fix

Temuan baru selesai ketika remediation telah diverifikasi.

Perspektif Developer: Cari Root Cause, Bukan Payload

Ketika SQLi ditemukan, developer kadang fokus pada payload yang lolos:

"Kalau karakter ini kita blok bagaimana?"

Itu biasanya arah yang salah.

Pertanyaan yang lebih baik:

"Di mana input tidak dipercaya bisa masuk ke SQL interpreter sebagai bagian dari syntax?"

Audit pola seperti:

• query concatenation;
• dynamic SQL;
• raw-query API;
• stored procedure yang masih membangun dynamic SQL secara tidak aman;
• ORM escape hatch / raw query;
• query builder yang digunakan secara keliru.

Fix root cause, bukan mengejar daftar karakter.

Dari Red Team ke Blue Team

SQLMap memberi kita kesempatan bagus untuk latihan Purple Team.

Red Team menjalankan detection terkontrol pada endpoint lab atau target assessment. Blue Team mencatat waktu dan mengamati:

HTTP Request
    ↓
Reverse Proxy / WAF
    ↓
Application
    ↓
Database
    ↓
Logs / APM / SIEM

Lalu bandingkan:

• aktivitas apa yang terlihat di edge;
• apa yang terlihat di application log;
• apa yang terlihat di database;
• alert mana yang muncul;
• berapa lama sampai analyst memahami konteksnya;
• apakah telemetry cukup untuk investigasi.

Kalau Red Team bisa membuktikan SQLi tetapi Blue Team tidak melihat apa pun, itu adalah detection gap yang sama pentingnya dengan vulnerability aplikasi.

Penutup

sqlmap adalah tool yang sangat powerful. Justru karena itu penggunaannya harus semakin terukur, bukan semakin sembrono.

Pelajaran terpenting dari artikel ini bukan command --dbs atau --level. Pelajarannya adalah workflow:

pahami request → pilih parameter → validasi dengan impact minimum → kumpulkan evidence → lihat detection → perbaiki root cause → retest.

Dan untuk remediation, jangan sibuk mencari regex ajaib. Pisahkan data dari SQL instruction menggunakan parameterized queries, terapkan least privilege, lalu bangun monitoring yang masuk akal.

Di artikel berikutnya, seri kita masuk ke dunia Active Directory dengan #06 BloodHound Cheat Sheet: Memahami Relationship dan Attack Path Active Directory.

Sumber Resmi

• sqlmap Project — https://sqlmap.org/
• sqlmap User Manual / Usage — https://github.com/sqlmapproject/sqlmap/wiki/Usage
• sqlmap FAQ — https://github.com/sqlmapproject/sqlmap/wiki/FAQ
• OWASP SQL Injection Prevention Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
• OWASP Injection Prevention Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html