SQL injection (SQLi) is one of the most critical web application vulnerabilities. This module covers UNION-based, blind, boolean-based, and time-based SQL injection techniques. Learn how to use sqlmap for automated exploitation, bypass WAFs, and implement prevention through parameterized queries.
The CEHStudy app carries 14 flashcards for Module 15 across 3 sections — learn the type tree cold (in-band: error-based and union; blind: boolean and time; out-of-band); every payload question resolves by naming which class the technique belongs to.
Key Topics Covered
SQL injection fundamentals and how it works at the query level
UNION-based SQL injection: combining results from multiple queries
Blind SQL injection: inferring data through true/false responses
Boolean-based blind SQLi: using HTTP response differences
Time-based blind SQLi: using SLEEP() and WAITFOR delays
UNION-based SQLi: Uses the UNION operator to combine results from the original query with an attacker-injected SELECT statement. Requires same number of columns in both queries.
Blind SQL Injection: No data is returned in the response. Attacker infers data by observing true/false responses or time delays. Slower but works when error messages are disabled.
Boolean-based Blind SQLi: Injects conditions that evaluate to TRUE or FALSE, observing differences in HTTP response content to infer data character by character.
Time-based Blind SQLi: Uses database-specific time functions (SLEEP(5) in MySQL, WAITFOR DELAY '00:00:05' in MSSQL) to infer data based on response timing.
sqlmap: Open-source tool that automates SQL injection detection and exploitation. Supports UNION, blind, time-based, error-based, out-of-band techniques. Can take full database control.
WAF Bypass: Techniques to evade Web Application Firewalls: encoding (%27 for single quote), double encoding, comment injection (--, #), character set manipulation, and chunk size attacks.
How to Study This Module
Understand how SQL injection works at the query level (concatenation of user input into queries)
Differentiate UNION-based vs blind vs boolean-based vs time-based techniques
Know sqlmap command-line options for different attack scenarios
Memorize prevention: parameterized queries are the single most effective defense
Frequently Asked Questions
What is SQL injection? Inserting malicious SQL code into input fields to manipulate backend database queries. Can lead to data theft, authentication bypass, and full database compromise.
What are the types of SQL injection attacks? In-band (UNION-based, error-based), Blind (boolean-based, time-based), and Out-of-band. In-band is easiest — attacker uses same channel for attack and results. Blind is slower but works when errors are hidden.
SQL Injection (SQLi) is the most critical and most commonly exploited web application vulnerability — a standalone module on the CEH v13 exam. SQLi occurs when an app concatenates unsanitized user input into SQL queries, letting an attacker manipulate the query's logic and execute arbitrary database commands. Unlike other injection flaws, it targets the relational database engine itself — MySQL, Microsoft SQL Server, PostgreSQL, Oracle, SQLite. Impact ranges from unauthorized data access (reading all tables) to complete database compromise (modifying/deleting data, executing OS commands via xp_cmdshell on MSSQL). Module 15 topics account for approximately 12% of CEH v13 exam questions.
Key Concepts in SQL Injection
UNION-Based SQL Injection & Column Counting: UNION-based SQLi appends an attacker-controlled SELECT to the existing query via UNION — both queries must have the same column count. Find it by injecting ORDER BY n and incrementing n until an error occurs (?id=1 ORDER BY 3 → error means fewer than 3 columns). Then inject NULL for non-displayed positions and data-extraction functions for displayed ones: ' UNION SELECT table_name,column_name,NULL FROM information_schema.columns--. Requires the application to display query results AND matching column counts. Enumerate tables and columns first from information_schema (MySQL) or sysobjects/syscolumns (MSSQL).
Blind SQLi: Boolean vs Time-Based Tradeoffs: Blind SQLi is used when the application shows no results or errors — data is inferred through side channels. Boolean-based: inject conditional logic (AND 1=1 / AND 1=2) and observe response differences — page length, element presence, HTTP status; one character per request. Time-based: inject sleep functions (SLEEP(5), WAITFOR DELAY '00:00:05', pg_sleep(5)) that fire only when a condition is true, and measure response time. Time-based runs 10-50x slower than boolean but works when responses are identical regardless of result. Key distinction: boolean needs an observable difference (even one pixel); time-based works when none exists. Both extract data one character at a time via SUBSTRING() or LEFT().
Out-of-Band SQLi & Stacked Queries: Out-of-band (OOB) SQLi exfiltrates data through a channel other than HTTP — typically DNS or HTTP callbacks — using database functions for outbound connections: MSSQL's xp_cmdshell + certutil, MySQL's LOAD_FILE() for local file read, PostgreSQL's COPY TO PROGRAM for OS command execution, Oracle's UTL_HTTP.request(). OOB works when the database server has internet access but the application returns no useful data. Stacked queries (multi-statement injection) run multiple SQL commands in one input, separated by semicolons: ' DROP TABLE users; --. Support varies: MySQL yes, MSSQL yes, PostgreSQL no (single-statement only), Oracle via PL/SQL blocks. OOB is the fallback when blind techniques are too slow or blocked — and it needs outbound network access from the database server.
Parameterized Queries as Primary Prevention: The single most effective SQLi prevention: parameterized queries (prepared statements). The query structure is sent to the database first; user input goes in separately as data parameters, which the engine treats strictly as data — never executable SQL. Example: not "SELECT * FROM users WHERE username='" + userInput + "'", but "SELECT * FROM users WHERE username = ?" with userInput bound as a parameter. Input validation (blacklisting SQL metacharacters) is NOT sufficient alone — encoding, comments, and alternative syntax bypass it. Parameterization separates code from data at the protocol level, making bypass impossible regardless of input.
Common Exam Mistakes in Module 15
Guessing UNION column counts by trial and error: a UNION SELECT fails unless column counts match — the disciplined step is ORDER BY n until the error flips, then NULL padding. Stems showing ' UNION SELECT username, password FROM users-- are in-band: the data returns in the same visible response.
Calling every no-output injection time-based: blind splits two ways — boolean, where responses differ for ' AND 1=1 versus ' AND 1=2 and leak one character at a time, and time-based, where an induced delay (MySQL SLEEP(5), SQL Server WAITFOR DELAY '0:0:5', PostgreSQL pg_sleep(5)) is the only channel. What you observe — page content or latency — picks the flavor.
Stopping the defense list at input validation: the stack starts with parameterized queries (prepared statements) separating code from data; stored procedures, least-privilege DB accounts, WAF rules, ORM frameworks, and suppressing raw database errors all belong in the same answer. Validation alone is not the strongest primary defense.
Tools Used in SQL Injection
Tools the CEH v13 exam references for SQL injection testing:
sqlmap: the automated standard — --dbs lists databases, -D dbname --tables lists tables, -T tbl --dump extracts rows; --os-shell and --passwords extend the test, and --batch --technique=B pins a technique class such as boolean blind for scripted runs
Burp Suite Repeater: manual SQLi iteration — single quotes, UNION SELECT, and conditional delays replayed one change at a time until the response flips
OWASP ZAP: free alternative with automated SQLi detection built into its active scan pass
Havij: GUI-based SQLi tool for Windows, the non-command-line option on the exam
Mantra: automated injection tool that sweeps form fields and URLs for SQLi without manual payload crafting
Modlishka: phishing plus SQLi in one package, referenced when a stem mixes credential capture with injection
DVWA / SQLi labs: deliberately vulnerable practice environments for hands-on exploitation before exam day
Worked Example: Login Bypass to OS Shell, Class by Class
On a login form, admin'-- in the username field comments out the password check — the same tautology logic as ' OR 1=1-- — and the app signs the tester in as administrator: first-order, in-band injection. Escalating, ' ORDER BY 3-- stops erroring while ORDER BY 4 errors, so the query has three columns; ' UNION SELECT username, password FROM users-- then dumps credentials inside the same visible response.
The twist: a second endpoint renders nothing, so the channel becomes latency — SLEEP(5) fires only when the injected condition is true, the signature of time-based blind. The database engine sets the post-exploitation ceiling: xp_cmdshell on SQL Server runs OS commands (often disabled by default); prepared statements from day one would have collapsed the chain, since injected SQL becomes inert data.
How to Study SQL Injection for the CEH v13 Exam
To study Module 15 for the CEH v13 exam:
Memorize the SQLi hierarchy: In-band (UNION-based, Error-based) → data returned in the same channel; Blind (Boolean, Time-based) → data inferred from response differences or timing; Out-of-Band → exfiltrated via DNS/HTTP callbacks. Exam stems classify scenarios and pick the technique for the constraints (e.g., "errors are suppressed, but responses differ" = boolean-based blind)
Hands-on: set up DVWA (Damn Vulnerable Web Application) with local MySQL. Practice error-based (invalid SQL forcing errors that reveal table structure), UNION-based (column counting, information_schema), and boolean blind (character-by-character iteration). For each, document the payload, what the response reveals, and the sqlmap command that automates it — this maps directly to scenario questions asking for the right technique
Memorize database-specific functions: MySQL — SLEEP(), BENCHMARK(), information_schema, LOAD_FILE(), INTO OUTFILE; MSSQL — WAITFOR DELAY, sysobjects, xp_cmdshell, OPENROWSET; PostgreSQL — pg_sleep(), information_schema, COPY TO PROGRAM; Oracle — UTL_HTTP.request(), all_tab_columns. Stems may name a database and ask which function handles time-based blind or exfiltration
Review related modules: Module 14 (Web Application Hacking) for the OWASP A03 (Injection) context and how SQLi fits into web application attack chains, and Module 13 (Web Server Hacking) for server-level misconfigurations (verbose errors, excessive database permissions) that increase SQLi success
Frequently Asked Questions About SQL Injection
How do you identify a potentially vulnerable parameter for SQL injection?
(1) Single quote test — append a single quote ('). An error referencing SQL syntax, a database query, or "unterminated string literal" means input is concatenated into SQL without sanitization; (2) Boolean test — append ' AND 1=1 vs ' AND 1=2; different responses (page length, content) mean the parameter affects query logic; (3) Time-based test — append ' AND SLEEP(5)-- or '; WAITFOR DELAY '00:00:05'--; a ~5-second delay confirms SQLi even without visible errors; (4) URL encoding — an error that disappears with %27 (URL-encoded quote) but returns when decoded server-side means the input is processed in SQL context; (5) Parameter position — numeric parameters that should be integers (e.g., ?id=1) are commonly vulnerable because type validation is skipped. A single quote is the fastest first check — confirmation requires demonstrating data manipulation or auth bypass, not just an error.
What WAF bypass techniques work against SQL injection filters?
(1) URL encoding — %27 for the quote, double-encoded %2527 if the WAF decodes only once; (2) Inline comments — MySQL syntax /*!...*/ breaks up keywords: UN/**/ION SEL/**/ECT; (3) Case variation — some WAFs are case-sensitive: SeLeCt, UnIoN, sLeEp(); (4) Alternative syntax — information_schema instead of SHOW TABLES, 0x41 (hex) instead of 'A'; (5) Chunked transfer encoding — split the payload across HTTP chunks so no chunk holds the full pattern; (6) HTTP parameter pollution — duplicate the parameter (?id=1&id=1 UNION SELECT...) to confuse WAF parsing while the app uses one value; (7) Character set manipulation — GBK/UTF-8 multi-byte characters whose trailing byte escapes a string context. No single bypass guarantees success — it depends on the specific WAF's rules and encoding behavior. Parameterized queries remain the reliable defense, making all bypasses irrelevant.