6.3 Injection: SQL Injection & Command Injection

EC-Council Certified Ethical Hacker CEH

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 CEH Exam Format, Cost & Eligibility 1.2 The Five Phases of Ethical Hacking 1.3 Information Security Fundamentals 1.4 Ethical Hacking Concepts, Scope & Legal Framework 1.5 The CEH Domains & Your Study Priority Map

2 Reconnaissance, Footprinting, Scanning & Enumeration

2.1 Footprinting & Reconnaissance Concepts 2.2 Footprinting Sources & Techniques 2.3 Network Scanning Concepts 2.4 Banner Grabbing, OS Fingerprinting & Scanning Beyond IDS/Firewall 2.5 Enumeration 2.6 Vulnerability Scanning & Countermeasures

3 Vulnerability Analysis & System Hacking Phases

3.1 Vulnerability Analysis Concepts 3.2 System Hacking Methodology Overview 3.3 Gaining Access: Password Attack Concepts 3.4 Privilege Escalation Concepts 3.5 Maintaining Access: Backdoors, Rootkits & Persistence 3.6 Covering Tracks, Anti-Forensics & Blue-Team Detection

4 Malware Threats, Sniffing & Social Engineering

4.1 Malware Concepts and Taxonomy 4.2 Malware Analysis and Detection 4.3 Sniffing Concepts and Layer 2 Attacks 4.4 Sniffing Countermeasures and Detection 4.5 Social Engineering Types and Human Psychology 4.6 Social Engineering and Insider Threat Defenses

5 Network & Perimeter Hacking

5.1 Denial of Service and DDoS Attacks 5.2 Session Hijacking 5.3 Evading IDS and IPS (Defensive Focus) 5.4 Evading Firewalls 5.5 Evading Honeypots and Defensive Deception 5.6 Network Security Controls and Architecture 5.7 Packet Analysis and Secure Protocols for Defenders

6 Web Server & Web Application Hacking

6.1 Web Server Attacks & Hardening 6.2 OWASP Top 10 Overview 6.3 Injection: SQL Injection & Command Injection 6.4 Cross-Site Scripting (XSS) & CSRF 6.5 Authentication, Session & Access-Control Flaws 6.6 API & Web App Security Testing Concepts

7 Wireless Network Hacking

7.1 Wireless Concepts and Standards 7.2 Wireless Encryption 7.3 Wireless Threats and Attack Concepts 7.4 Wireless Security Countermeasures

8 Mobile Platform, IoT & OT Hacking

8.1 Mobile Platform Threats & Security Models 8.2 Mobile Attack Vectors & Risks 8.3 Mobile Device Management & Enterprise Defense 8.4 IoT Hacking Concepts & Defense 8.5 OT, ICS & SCADA Security

9 Cloud Computing & Cryptography

9.1 Cloud Computing Concepts 9.2 Cloud Threats & Attack Surfaces 9.3 Cloud Security Controls 9.4 Cryptography Fundamentals 9.5 PKI & Cryptographic Applications 9.6 Cryptanalysis, Crypto Attacks & Best Practices

6.3 Injection: SQL Injection & Command Injection

Key Takeaways Explain This Topic AI

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.

Last updated: June 2026

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.