sqlmap
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.
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'
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.
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
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
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
--os-shell writes to the target and can leave artefacts; never run it outside an authorized, ideally isolated, environment.
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.
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:
- Philippines: Cybercrime Prevention Act of 2012 (Republic Act No. 10175)
- United States: Computer Fraud and Abuse Act (18 U.S.C. § 1030)
- United Kingdom: Computer Misuse Act 1990
- European Union: Directive 2013/40/EU on attacks against information systems, as implemented by each member state
- Most other countries have equivalent computer-misuse laws
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.