Explained Live · lesson 2 · 2026-09-04 · updated 2026-10-12

How SQL Injection Works — See It Happen Live

▶

Before you start

• DVWA (Damn Vulnerable Web App, a deliberately vulnerable practice app) from the vulnerables/web-dvwa Docker image, bound to 127.0.0.1:8080, security level low.
• Logged in as admin / password with the session cookie saved to lab/cookies.txt (curl -b lab/cookies.txt ...), so the on-screen commands stay short.
• curl (preinstalled on Kali).
• Only test systems you own or are authorized to test.

SQL injection is one of the most searched vulnerabilities on the web — and once you see it happen, you will never look at a login form the same way again. In this video, we run a live SQL injection attack against a practice app, pull data straight out of the database with one crafted request, and walk through exactly why it works and how to close the gap. This is a standalone video, and it connects to a beginner Web Application Security series on this channel if you want to go deeper. Let’s get into it.

Let’s start with the concept.

What is SQL injection?

• Your app talks to its database using a language called SQL
• A query looks like this: SELECT * FROM users WHERE id = 1
• The app builds that query using input YOU provide
• SQL injection = slipping extra SQL instructions into that input
• The database reads your code as part of the query — and obeys it

Every time you search for a product, look up an order, or log in, your browser sends a value to the server. The server takes that value and builds a database query around it. Something like: SELECT everything FROM users WHERE the I.D. equals whatever you sent. The vulnerability happens when the server drops your input directly into that query without checking it first. If you send something that looks like SQL instead of a plain value, the database reads it as a command.

Here is what that looks like in practice.

A normal query vs. an injected one

SELECT * FROM users WHERE id = '1' OR 1=1 -- -'

The original query was supposed to return only the user whose I.D. is one. But we appended ‘OR 1=1’, which is always true. Now the WHERE clause matches every row in the table. The double-dash at the end is a SQL comment — it tells the database to ignore the rest of the original query so nothing breaks. With those two additions, we turned a filtered lookup into a full table dump.

Let’s run it. Our practice target is a local OWASP DVWA app running on 127.0.0.1. First a normal request.

Step 1 — a normal lookup

curl -s -b lab/cookies.txt "http://127.0.0.1:8080/vulnerabilities/sqli/?id=1&Submit=Submit" | grep -oP "(First name|Surname): \w+"

One user — admin. That is the expected result. The query ran correctly and returned only the record for I.D. one. Now we change the value we send.

Step two — we inject. Instead of a number, we send a single quote to break out of the string, then ‘OR 1 equals 1’, then a comment to close the original query.

curl -s -b lab/cookies.txt "http://127.0.0.1:8080/vulnerabilities/sqli/?id=%27+OR+1%3D1+--+-&Submit=Submit" | grep -oP "(First name|Surname): \w+" | head -6

Three users returned — and we only asked for one. The app gave us admin, Gordon Brown, and Hack Me. If we removed the head six limit it would return every user in the database. We did not guess any passwords. We did not need any credentials beyond our normal login. We just changed the value in the URL.

Now we go further. SQL injection also lets us run completely different queries using UNION SELECT — as long as we match the number of columns the original query returns.

What UNION SELECT does

• UNION joins a second SELECT query onto the first one
• We pick exactly which table and columns to read
• The database returns our chosen data alongside the original results
• Here: we read the users table — usernames and password hashes

curl -s -b lab/cookies.txt "http://127.0.0.1:8080/vulnerabilities/sqli/?id=%27+UNION+SELECT+user%2Cpassword+FROM+users+--+-&Submit=Submit" | grep -oP "(First name|Surname): [a-zA-Z0-9]+" | head -8

Every username and its password hash, pulled directly from the database. Admin, gordonb, pablo, smithy — and their hashed passwords. These are MD5 hashes, which are weak and can be reversed with a lookup table in seconds. One crafted URL and the entire credentials table is out in the open. That is what the 148,000 people who watched the top-ranked video on this topic came to understand — and now you have seen it happen live.

How do you find this, and how do you fix it?

Find it. Fix it.

• FIND: send a single quote ’ in any input field or URL parameter
• FIND: a database error or unexpected result means injection may be possible
• FIX: use prepared statements — the query is compiled before any input is added
• FIX: with prepared statements, your input is always treated as data, never as code
• FIX: validate and whitelist inputs on the server — never on the client only

The fix is called a prepared statement, and it is the industry standard. In a prepared statement, the database compiles the query first — the structure is locked before any user input arrives. When the input comes in, it is treated as a plain value, never as executable code. Even if someone sends ’OR 1=1, the database reads it as a string, not as SQL. Parameterized queries, ORMs, and stored procedures all enforce the same principle. The single quote test is the quickest way to find the gap — if the app throws a database error or returns unexpected rows, there is probably an injection point.

One rule, every time.

Before you go

• Only test apps you own or have written permission to test
• DVWA is built for exactly this — run it locally to practise safely
• O-WASP tracks this as A-03 Injection in their top ten web application risks
• The full Web Application Security beginner series is on this channel — link below

Only ever test applications you own or have explicit written permission to test. Sending a crafted SQL parameter to a site you do not own is still an unauthorized test, even if it looks harmless. DVWA is built for this exact kind of safe, legal practice — it runs entirely on your local machine. The O-WASP project lists SQL injection under A-03 Injection in their top ten web application risks, and it has been in that list every year since it was first published. If you want to go deeper, the full Web Application Security beginner series is linked in the description — Parts one through four are already up. Thanks for watching, and I will see you in the next one.