Day 13: SQL Injection Explained — From First Quote to Finding the Vulnerability (2026)
📰 Originally published on SecurityElites — the canonical, fully-updated version of this article.
DAY 13 OF 100 PHASE 2: WEB SECURITY
🟢 Day 13 — SQL Injection Tutorial
Day 100 — Professional Pentester
⚖️ Authorisation required: All SQL injection testing in this lesson is performed exclusively on DVWA running in your own lab environment — a deliberately vulnerable application designed for this exact purpose. Attempting these techniques against any production system, website, or service you do not own or have explicit written permission to test is illegal under computer crime laws in every jurisdiction. Security professionals carry written scope agreements for every engagement.
13
A single apostrophe. One character. That’s how this vulnerability begins. A developer builds a login form, connects it to a database, and passes the username directly into a SQL query without thinking about what happens if the user types something unexpected. The attacker types something unexpected — and suddenly the database is answering questions it was never meant to answer.
SQL injection has been on the OWASP Top 10 since 2003. It’s been responsible for some of the largest data breaches in history. And it’s still being found in new code every single day. Today you’ll understand exactly why — not from memorised rules, but from understanding how databases and queries work at a fundamental level.
SQL injection sits at #3 on the OWASP Top 10 — under the broader “Injection” category. It’s the vulnerability that gave attackers the LinkedIn passwords of 117 million users, the Adobe credentials of 153 million accounts, and the card data of 40 million Target customers. Understanding it is not optional for anyone working in web application security.
📋 Day 13 Contents
- How Databases & SQL Queries Work
- Why SQL Injection Happens
- The Single Quote Test — First Step
- Types of SQL Injection
- Error-Based SQLi in Burp Repeater
- UNION-Based SQLi Explained
- Blind SQL Injection
- sqlmap — Automating Detection
- Prevention — Parameterised Queries
- Day 13 Practical Task
How Databases & SQL Queries Work — The Foundation
To understand SQL injection you first need to understand what a SQL query actually is and how an application builds one. Most web applications store their data — user accounts, posts, products, orders — in a relational database like MySQL, PostgreSQL, or MSSQL. The application retrieves data by sending SQL (Structured Query Language) queries to the database.
A typical login query — how most developers write it
The users table in the database
┌─────┬──────────┬──────────────────────────────────────┐ │ id │ username │ password_hash │ ├─────┼──────────┼──────────────────────────────────────┤ │ 1 │ admin │ 5f4dcc3b5aa765d61d8327deb882cf99 │ │ 2 │ alice │ 0d107d09f5bbe40cade3de5c71e9e9b7 │ └─────┴──────────┴──────────────────────────────────────┘
PHP code building the login query (VULNERABLE pattern)
$username = $_POST[‘username’]; // Gets from login form $password = $_POST[‘password’]; $query = “SELECT * FROM users WHERE username = ‘$username’ AND password = ‘$password'”;
What the query looks like with NORMAL input:
username = admin → WHERE username = ‘admin’ AND password = ‘…’
Database checks if admin exists with that password. Fine.
What the query looks like with MALICIOUS input:
username = admin’– → WHERE username = ‘admin’–‘ AND password = ‘…’
The — comments out everything after it
The password check is gone. “admin” logs in without a password.
The critical point: the developer intended '$username' to be a string value inside the query. The apostrophes were meant to delimit the string. But when the attacker includes their own apostrophe in the input, they break out of the string context and enter the SQL command context. Now they’re writing SQL, not just providing data.
Why SQL Injection Happens — The Root Cause
SQL injection is not a subtle bug. It’s a fundamental category error: the application fails to maintain the distinction between code (the SQL structure) and data (user input). When these two things are mixed together in a string concatenation, user data can be interpreted as code.
❌ VULNERABLE — String Concatenation query = “SELECT * FROM users WHERE id = ” + user_id User data is inserted directly into the SQL string. The database cannot tell where the developer’s code ends and the user’s input begins.
✅ SAFE — Parameterised Query query = “SELECT * FROM users WHERE id = ?” execute(query, [user_id]) SQL structure is sent separately from data. The database treats user_id as pure data, never as SQL code. Injection is structurally impossible.
The Single Quote Test — How Testers Identify SQLi
In an authorised penetration test, the first thing a tester does to check for SQL injection is also the simplest: submit a single apostrophe ' into every input field that might reach a database query. If the application is vulnerable and doesn’t handle it properly, one of several things happens — and each response tells you something different.
What different responses to a single quote mean — in Burp Repeater
DVWA SQL Injection page — normal request
GET /dvwa/vulnerabilities/sqli/?id=1&Submit=Submit Response: First name: admin Surname: admin
Inject a single quote
GET /dvwa/vulnerabilities/sqli/?id=1’&Submit=Submit
Possible responses and what each means:
Response A: SQL error message visible
You have an error in your SQL syntax… near ”1”’ at line 1
→ Error-based SQLi confirmed. Quote broke the query structure.
Response B: Application error, no SQL detail
500 Internal Server Error / “Something went wrong”
→ Likely vulnerable but errors suppressed. Try blind techniques.
Response C: Different output (fewer/more results)
User ID exists in the database. ← vs no output for id=1′
→ Boolean-based blind SQLi. Application behaves differently.
Response D: Same output as without the quote
First name: admin Surname: admin ← same as before
→ Input might be sanitised, or numeric (quotes not relevant)
→ Try: id=1 OR 1=1– or id=1 AND 1=2 (no quotes needed)
📖 Read the complete guide on SecurityElites
This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on SecurityElites →
This article was originally written and published by the SecurityElites team. For more cybersecurity tutorials, ethical hacking guides, and CTF walk-throughs, visit SecurityElites.
