How to Exploit SQL Injection: Step-by-Step (DVWA Lab)

In one line

SQL injection is when you type database commands into a normal input box, and because the app pastes your text straight into its query, the database runs your commands instead of just treating them as data.

What this is, for a beginner

A web application builds a database query out of text, and if it glues your input directly into that query, your input can change what the query means. SQL injection is exactly that: instead of treating your input as a value to look up, the database treats part of it as SQL to execute. That single mistake can leak the entire database.

It usually shows up in login forms, search boxes, and any parameter that feeds a lookup. The two classic outcomes are authentication bypass, where you trick the login into always being true, and data extraction, where you use a UNION query to append the database contents to the app's normal results. Both come from the same root cause: untrusted input landing in a query unparameterised.

The legal lab we use: DVWA

The Damn Vulnerable Web Application is built to be exploited legally. Run it locally so every payload hits software you own.

DVWA project page →

Full walkthrough: exploiting it step by step

Step 1 — Set up DVWA and set security to Low

Run DVWA locally, log in, and set DVWA Security to Low so the injection is unfiltered while you learn the mechanics. Open the SQL Injection page, which asks for a User ID.

Expected result: The SQL Injection page loads with a text box for a User ID and a Submit button.

Step 2 — Confirm the injection point

Enter a normal value first to see baseline behaviour, then a single quote to break the query syntax. If the app is injectable, the stray quote produces a SQL error or a change in behaviour.

User ID field

1'

Expected result: A database error or an obviously broken response, confirming your input reaches the query unescaped.

Step 3 — Bypass logic with an always-true condition

Now make the WHERE clause always true so the query returns every row rather than one. This is the canonical proof-of-concept for SQL injection.

User ID field

1' OR '1'='1

Expected result: The page returns every user record instead of one, because you turned the lookup condition into something always true.

Step 4 — Find the number of columns

To extract data with UNION you must match the column count of the original query. Increase the number of columns in an ORDER BY until it errors; the last value that works is the column count.

increment until it errors

1' ORDER BY 2-- -

Expected result: ORDER BY 2 works, ORDER BY 3 errors, telling you the query returns two columns.

Step 5 — Extract data with UNION

With the column count known, append a UNION SELECT to pull real data out of the database, such as the version, current database, or user table contents.

User ID field

1' UNION SELECT user, password FROM users-- -

Expected result: Usernames and password hashes from the users table appear in the page output, alongside or instead of the normal result. That is full data extraction via SQL injection.

Step 6 — Raise the difficulty

Set DVWA Security to Medium and High and try again. Medium often uses a dropdown and basic escaping you can work around; High adds more filtering. Working up the levels teaches you how real defences change the attack, and the PortSwigger Web Security Academy SQL injection labs are an excellent next step.

Expected result: The same logic still works with adjusted payloads, showing how filtering raises the bar without necessarily closing the hole.

Free resource

Get the free 35-week ethical hacking roadmap

The exact order I'd learn this in, every vulnerability and tool, week by week, with the labs to practise each one. Enter your email and I'll send it over, plus one practical lesson each week.

How to detect and fix this

How to detect it

Test every parameter that could reach a query with a single quote and with a known-true or known-false condition; a difference in response between true and false conditions signals injection even when no error is shown (blind SQL injection).
Automated help exists (SQLmap) but confirm findings by hand so you understand the exact injection point and impact rather than trusting a tool blindly.
Review code for any query built by concatenating strings; that pattern is the root cause and is far faster to spot in source than to find by probing.

How to fix it

Use parameterised queries (prepared statements) everywhere, so user input is always sent as data and never becomes part of the SQL. This is the real fix, not input filtering.
Prefer an ORM or query builder that parameterises by default, and treat any raw string-built query as something that needs review.
Apply least privilege to the database account the app uses, so even a successful injection cannot read or change more than necessary.
For a deeper explanation of the class and its variants, read our full guide to SQLmap and to command injection, which share the same untrusted-input root cause.

Common beginner mistakes

Forgetting the comment sequence at the end of a payload, so the rest of the original query breaks it. Use a trailing comment to discard whatever follows.
Guessing column counts instead of finding them with ORDER BY, which wastes time and produces confusing UNION errors.
Only testing for error-based injection and giving up when no error appears, missing blind injection that is detectable through true/false response differences.
Running payloads against a site you do not own. Practise only in DVWA, a PortSwigger lab, or an application you are authorized to test.

FAQ

What is the difference between error-based and blind SQL injection?

Error-based injection reveals data or database errors directly in the response, making extraction straightforward. Blind injection returns no visible error or data, so you infer results from indirect signals such as whether a true or false condition changes the page or its timing. Both stem from the same flaw.

Is SQL injection still common?

Yes. It is less universal than a decade ago thanks to ORMs and prepared statements, but it still appears regularly, especially in older code, custom queries, and places developers built SQL by hand. It remains a core skill because the impact is so high.

Should I use SQLmap or do it by hand?

Learn it by hand first so you understand the injection point and can validate results, then use SQLmap to automate extraction once you know what you are doing. Relying on the tool without understanding leads to false positives and missed context.

Where to go from here

You just exploited one vulnerability in a lab. Here's the structured path.

Scattered tutorials teach you tricks; they don't make you a pentester. My mentorship is 35 weeks of exactly this, every vulnerability and tool in a deliberate order, on real labs, with one-on-one feedback on your work so your mistakes get caught early instead of becoming habits.

See the mentorship

Keep practising

How to Use SQLmap How to Exploit Command Injection How to Use Burp Suite