sqlmap: database exploitation from zero to dump / —

First Injection

You are testing the ACME Store, a small web shop at http://10.11.12.18. You have not seen any of its pages yet, and you cannot attack an input until you have found one.

Your task

Explore the site with curl, find a page that takes a user controlled value in its URL, and then use sqlmap to confirm that value is injectable. Success is sqlmap reporting the parameter as an injection point.

💡 Hint: Start at the top with curl http://10.11.12.18/ and read the HTML it returns, then follow the links it points to. Watch for an HTTP GET parameter, a value after a ? in a URL like page?thing=1. GET parameters are the classic first place user input reaches a database. Once you have found one, the most basic sqlmap run is sqlmap -u "URL" --batch (quote the URL, it contains a ?).

What is SQL injection? (click to expand)

The flaw

When an application builds a query by pasting your input directly into the SQL string, you can break out of the data and change the query itself. Here the page runs something like SELECT ... WHERE id = <your input>, so an input of 1 AND 1=1 and 1 AND 1=2 return different pages. That difference is a leak.

What sqlmap does

sqlmap automates the tedious part. It fires hundreds of crafted payloads and watches how the responses change, then classifies the injection by type: boolean-based (true/false pages differ), error-based (the DB error text leaks out), time-based (it can make the DB sleep), and UNION-based (it can append its own result set). One page can be vulnerable to several at once.

Fingerprint the Backend

When sqlmap confirmed the injection a moment ago, it also fingerprinted the backend and printed a back-end DBMS: line, so you already know which database engine you are up against. What it did not spell out is the exact version.

Your task

Pull the full version banner of the database, so you have the precise release and not just the product name.

💡 Hint: Run sqlmap --help (or the fuller sqlmap -hh) and look under Enumeration. One flag pulls the DBMS banner string. Keep the same -u target and --batch.

Engine versus exact version (click to expand)

The banner tells you the engine and version, for example a MariaDB or MySQL release. That decides which functions and tricks are available: how comments are written, whether stacked queries work, which system tables hold the schema. sqlmap already fingerprints the backend during detection and prints a back-end DBMS line, but pulling the full banner confirms the exact version, and a version number is the first thing you match against public vulnerabilities.

Find the Current Database

A single server often hosts many databases. You want to know which one this application is actually using, and who you are connected as.

Your task

Get sqlmap to reveal the name of the database the application is currently using.

💡 Hint: Still in the Enumeration section of the help. There is a flag for the current database and a matching one for the current user. Both are worth running.

Orientation before extraction (click to expand)

Knowing the current database narrows your search: you do not have to trawl every schema on the server, you can focus on the one the app trusts. The current user matters too. If it turns out to be a high privilege account you may be able to read files or reach other databases; a locked down account limits you to the app's own data. Enumeration is about building this map before you start pulling rows.

Enumerate the Tables

You have a database name. Time to look inside it.

Your task

List the tables inside the shopdb database. You should see more than just products in there.

💡 Hint: Two flags combine here. One selects a specific database by name (an uppercase -D), and one asks for the tables in it. Restricting to a single database keeps the output focused and the queries fast.

Reading the target (click to expand)

The interesting tables jump out by name. A users table almost always holds credentials; anything called secrets, config or tokens is worth a look. Good enumeration is targeted: you are not dumping everything blindly, you are reading the schema to decide what is actually worth extracting.

Map the Columns

Before dumping a table, it helps to know its shape: which columns exist and what they are called.

Your task

List the columns of the users table in shopdb.

💡 Hint: Build on the last command. You already know how to select a database with -D; add the flag that selects a table (uppercase -T) and the one that asks for its columns.

Why not just dump everything? (click to expand)

On a real target a table can have millions of rows, and blind extraction pulls them one character at a time. Knowing the columns lets you dump only what you need, for example just username and password, which can be the difference between a scan that finishes in seconds and one that runs for hours and gets you caught.

Dump the Credentials

You have mapped the users table. Now take it.
Dump the contents of the username and password (in this order) columns from the table.

Your task

Dump the contents of the users table in shopdb and read the stored credentials.

💡 Hint: Keep your -D and -T selectors and add the flag that dumps table data. You can narrow it further with -C to name specific columns if you only want a few.

Passwords in the clear (click to expand)

This app stores passwords in plaintext, which is its own serious bug. On a real target you would usually get hashes instead, and sqlmap can try to crack common ones for you with a built in dictionary. Either way, dumped credentials are rarely the end of the story: people reuse passwords, so the admin account you just read may open SSH, the mail server, or the next box entirely.

Injection Beyond the URL

Not every injectable parameter sits in the query string. The login form at http://10.11.12.18/login submits a username and password in the POST body, and one of those fields is just as vulnerable as the product id was.

Your task

Use sqlmap to find and confirm the injection in the login form's POST data. Success is sqlmap reporting a POST parameter as an injection point.

💡 Hint: Point -u at the login URL and supply the body with the --data flag, for example --data "username=x&password=x". sqlmap treats each field in there as a testable parameter. (A tidier alternative for complex requests: save a raw HTTP request to a file and pass it with -r.)

Requests are attack surface (click to expand)

Any value the server trusts can be an injection point: POST fields, JSON bodies, custom headers, the Referer, even the User-Agent. The -r workflow is what professionals use in practice: capture a real request in Burp or from the browser, save it, and let sqlmap replay and mutate it exactly as the app expects, cookies and all.

Cookie Injection and Scan Depth

The page at http://10.11.12.18/dashboard decides what to show based on a uid value in your cookie. By default sqlmap does not bother testing cookies, so this one hides until you tell sqlmap to dig deeper.

Your task

Find the injection in the uid cookie on the dashboard. You will need to both supply the cookie and raise sqlmap's test depth so it actually probes there.

💡 Hint: Pass the cookie with --cookie "uid=1", and raise --level above 1. Level 2 adds cookie testing; level 3 adds headers. Higher levels are slower but reach parameters the default scan skips.
Oh and you might need some additional tweaking for sqlmap to find this SQLi.

Level, risk, and tuning (click to expand)

--level (1 to 5) controls how many places and payloads sqlmap tries; --risk (1 to 3) controls how dangerous those payloads are, since higher risk includes things like OR based tests that could modify data. You can also force a specific method with --technique (for example T for time-based only) when a target is picky. Tuning these is the difference between a scan that misses a bug and one that finds it without wrecking the target.

Capstone: Extract the Flag

Time to put it together. Somewhere in shopdb there is a table that is not products and not users. It holds a single secret, and that secret is your flag.

Your task

Using any injection point you have found, extract the flag from the secrets table. Dump it, or run a targeted query for just that column, whichever you prefer.

💡 Hint: Two good routes. Either enumerate and --dump the secrets table like you dumped users, or skip straight to it with --sql-query "SELECT flag FROM secrets", which runs an arbitrary read for you. --sql-shell drops you into an interactive SQL prompt over the injection if you want to explore.

Where to go from here (click to expand)

Going further with sqlmap

You have covered detection, fingerprinting, enumeration, dumping, alternate injection points and scan tuning. The tool goes much deeper:

--sql-shell and --sql-query run arbitrary SQL. --passwords dumps and tries to crack DB account hashes. --tamper loads evasion scripts to slip payloads past a web application firewall. On a misconfigured server with the right privileges, --file-read, --file-write and --os-shell reach the filesystem and even a command shell. This lab's database account is deliberately restricted to read only, so those last three will not work here, which is itself the lesson: least privilege on the database user turns a catastrophic breach into a contained one.

The defensive takeaway

Every challenge here existed because the app pasted input into a query. Parameterised queries (prepared statements) close all of it at once. sqlmap is how you prove the bug is real; parameterisation is how you make sure there is nothing for it to find.