You are testing the ACME Store, a small web shop at http://acmeshop. You have not seen any of its pages yet, and you cannot attack an input until you have found one.
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 withcurl http://acmeshop/ 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 likepage?thing=1 . GET parameters are the classic first place user input reaches a database. Once you have found one, the most basic sqlmap run issqlmap -u "URL" --batch (quote the URL, it contains a? ).
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
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.
When sqlmap confirmed the injection a moment ago, it also fingerprinted the backend and printed a
Pull the full version banner of the database, so you have the precise release and not just the product name.
💡 Hint: Runsqlmap --help (or the fullersqlmap -hh ) and look under Enumeration. One flag pulls the DBMS banner string. Keep the same-u target and--batch .
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
A single server often hosts many databases. You want to know which one this application is actually using, and who you are connected as.
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.
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.
You have a database name. Time to look inside it.
List the tables inside the
💡 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.
The interesting tables jump out by name. A
Before dumping a table, it helps to know its shape: which columns exist and what they are called.
List the columns of the
💡 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.
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
You have mapped the
Dump the contents of the username and password (in this order) columns from the table.
Dump the contents of the
💡 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.
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.
Not every injectable parameter sits in the query string. The login form at http://acmeshop/login submits a username and password in the POST body, and one of those fields is just as vulnerable as the product id was.
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 .)
Any value the server trusts can be an injection point: POST fields, JSON bodies, custom headers, the
The page at http://acmeshop/dashboard decides what to show based on a
Find the injection in the
💡 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.
Time to put it together. Somewhere in
Using any injection point you have found, extract the flag from the
💡 Hint: Two good routes. Either enumerate and--dump thesecrets 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.
You have covered detection, fingerprinting, enumeration, dumping, alternate injection points and scan tuning. The tool goes much deeper:
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.