6.3 Injection: SQL Injection & Command Injection
Key Takeaways
- Injection occurs whenever untrusted input is mixed into an interpreter's instruction (a SQL query, an OS command, a file path) so the input changes the instruction's structure instead of being treated as data.
- SQL injection is classified by data channel: in-band (results returned directly, e.g., error-based or UNION-based), blind/inferential (no direct output; boolean or time-based inference), and out-of-band (data exfiltrated over a separate channel like DNS).
- Command injection lets attacker input reach an operating-system shell, turning a web request into arbitrary OS command execution under the web service account.
- File inclusion (LFI/RFI) abuses an include/require path built from user input: LFI exposes local files and can reach code execution via log poisoning, while RFI pulls and runs attacker-hosted code.
- The definitive defense for SQL injection is parameterized queries (prepared statements); for command injection, avoid invoking a shell and pass arguments as a safe array; sqlmap and Burp Suite are the tools CEH associates with testing these flaws.
Why Injection Happens (the Root Cause)
Every injection vulnerability shares one root cause: untrusted input is concatenated into an instruction that an interpreter will parse. When an application builds a database query, an operating-system command, or a file path by gluing user input directly into a string, the interpreter cannot tell the developer's intended structure from attacker-supplied structure. The input stops being data and becomes code. CEH expects you to articulate this cause precisely, because the remediation follows directly from it: keep code and data separate.
Injection sits at A05 in the OWASP Top 10:2025 and famously includes both SQL injection and cross-site scripting under one umbrella.
SQL Injection (SQLi) Concepts
SQL injection (SQLi) targets the database tier. By influencing the structure of a query, an attacker can read data they should not see, bypass authentication logic, modify or delete records, or in some configurations reach the underlying host. CEH classifies SQLi by how the attacker gets data back:
- In-band SQLi — the attacker uses the same channel to inject and to receive results.
- Error-based: the application returns database error messages that leak structure or data.
- UNION-based: results from other tables are appended to the application's normal result set.
- Blind / inferential SQLi — the application returns no data or errors, so the attacker infers information one bit at a time.
- Boolean-based: page behavior differs between a query that evaluates true vs. false.
- Time-based: the attacker observes whether the response is delayed (e.g., a sleep condition) to infer a true/false answer.
- Out-of-band SQLi — results are exfiltrated over a different channel (for example, a DNS or HTTP callback) when in-band retrieval is not possible.
| SQLi class | How data returns | Telltale sign |
|---|---|---|
| Error-based (in-band) | Direct, via DB error text | Verbose SQL errors in the response |
| UNION-based (in-band) | Direct, appended to results | Extra/foreign rows in normal output |
| Boolean blind | Inferred from page state | True vs. false changes the page |
| Time-based blind | Inferred from response delay | Conditional response latency |
| Out-of-band | Separate channel (DNS/HTTP) | Outbound callback to attacker host |
These are conceptual categories; CEH tests recognition and defense, not payload authoring. The tool CEH most associates with automated SQLi discovery is sqlmap, often paired with Burp Suite to capture and replay requests.
Command Injection Concepts
OS command injection occurs when a web application passes untrusted input into a system shell — for example, a feature that runs a network diagnostic (ping) using a hostname the user supplied. Because the input reaches a shell, the attacker can append additional commands (using shell metacharacters) and execute them with the privileges of the web service account. The impact is typically severe: full command execution on the server, often leading to a complete host compromise and a foothold for lateral movement.
Conceptual, non-operational note: the danger is invoking a shell with a string the user can influence. The fix is structural (below), not filtering for "bad characters," which attackers bypass with encoding and alternate separators.
File Inclusion: LFI and RFI
A related injection class abuses dynamic include/require statements whose path comes from user input:
- Local File Inclusion (LFI) — the application includes a local file chosen by user input. An attacker can read sensitive local files and, by log poisoning or session-file tricks, sometimes escalate to remote code execution by getting attacker-controlled content interpreted as code.
- Remote File Inclusion (RFI) — the application includes a file from a remote URL supplied by the attacker, directly executing attacker-hosted code on the server. RFI requires risky configuration (e.g., allowing remote URL includes) and is therefore rarer but more immediately devastating.
Fix: never build an include path from raw input; use an allow-list of permitted module names mapped server-side, and disable remote-URL inclusion in the runtime configuration.
Defenses (Highest Yield on CEH)
Rank the defenses the way CEH does — the first item is the definitive fix; the rest are defense in depth:
| Defense | What it does | Layer |
|---|---|---|
| Parameterized queries / prepared statements | Query structure is fixed and compiled separately from data; input is bound as a parameter and can never be parsed as SQL | Primary fix for SQLi |
| Avoid shell invocation; use safe APIs | Call programs with an argument array instead of a shell string, so input cannot add commands | Primary fix for command injection |
| Allow-list module/path mapping | Map a fixed set of identifiers to files server-side; disable remote includes | Primary fix for LFI/RFI |
| Allow-list input validation | Accept only inputs matching a strict expected format (type, length, pattern) | Defense in depth |
| Least-privilege database account | The app's DB user has only the rights it needs, limiting blast radius if SQLi still occurs | Containment |
| Stored procedures (parameterized) | Encapsulate queries — effective only if they do not build dynamic SQL from input | Defense in depth |
| Web Application Firewall (WAF) | Blocks known injection patterns at the edge | Compensating control |
The exam trap to avoid: choosing "input validation" or "a WAF" as the best defense against SQL injection. They help, but only parameterized queries address the root cause by guaranteeing input is treated as data.
An application returns no error messages and no visible data difference, but the tester confirms a database flaw by observing that a manipulated request takes about 10 seconds to respond when a condition is true and responds instantly when it is false. Which SQL injection category is this?
Which single control most directly eliminates the root cause of SQL injection?
A web feature runs an operating-system network diagnostic using a hostname the user types in. The greatest risk if this input reaches a system shell unsanitized is:
An application builds an include path directly from a user-supplied parameter and the runtime is configured to allow remote URLs. An attacker supplies a URL to a file they host, and the server executes that code. Which flaw is this?