SQL Injection (SQLi)
1 Global Definition
SQL Injection (SQLi) is a web application vulnerability that allows attackers to interfere with the queries an application makes to its database. By injecting malicious SQL code into input fields, attackers can bypass authentication, extract sensitive data, modify databases, or even gain administrative control over the server.
1.1 Types of SQL Injection
Classic (In-band)
Attacker sees results directly in the application response.
- Error-based: Exploits database error messages
- Union-based: Combines queries with
UNION SELECT
Blind SQLi
No direct output, but attacker infers data indirectly.
- Boolean-based: Uses true/false conditions
- Time-based: Exploits delays to extract data
Out-of-Band SQLi
Uses external communication (e.g., DNS or HTTP requests) to exfiltrate data when direct interaction is blocked.
1.2 Common patterns
Attackers commonly rely on a few general input‑manipulation patterns to alter the logic of SQL queries. For defensive purposes you should be familiar with these high‑level patterns (do not use actual payload strings on public sites):
- Tautology patterns — inputs crafted to make conditional expressions always true.
- Union / additional‑result patterns — attempts to combine attacker‑controlled queries with application queries to reveal extra rows.
- Error‑based patterns — inputs that provoke database errors which may leak internal information.
- Timing/inference patterns — techniques that infer data by measuring response times or behavior.
- Out‑of‑band/exfiltration patterns — using external channels (DNS/HTTP callbacks) to retrieve data when direct output is blocked.
These pattern names are helpful for detection and classification in logs and IDS systems — do not publish, link to, or provide runnable exploit strings on public pages.
1.3 Defensive checklist & detection
Focus on prevention, detection, and safe testing. Use the checklist below to harden applications and to investigate potential SQLi safely.
- Use parameterized queries / prepared statements — separate code from data so user input cannot change query structure.
- Use least privilege — ensure DB accounts used by the app have minimal permissions (avoid using admin/root DB accounts for app queries).
- Input validation & canonicalization — validate input types and lengths; reject suspicious input at the boundary where possible.
- Use ORMs or safe query builders — prefer well‑maintained libraries that avoid manual string concatenation of SQL.
- Escaping & output handling — escape data for the relevant context and avoid reflecting raw DB errors to users.
- Logging & monitoring — capture anomalous inputs, unexpected errors, sudden increases in query volume, and high‑latency patterns for investigation.
- WAF / filtering — use a web application firewall as an additional, defense‑in‑depth measure (not a replacement for secure code).
- Test in authorized labs only — if you perform security testing, do so on sanctioned, isolated environments (e.g., intentionally vulnerable VMs) and obtain written permission.
For developer‑level guidance, consult OWASP’s SQL Injection Prevention Cheat Sheet (linked below).
1.4 Real-World Impact
- Data breaches (credit cards, credentials, personal info)
- Bypass authentication and gain admin access
- Data tampering or deletion
- Full compromise of backend infrastructure
- Used in major breaches (e.g., Sony, Heartland Payment Systems)
1.5 Why It Matters
SQL Injection remains one of the OWASP Top 10 web vulnerabilities due to its prevalence and severity. A single overlooked input field can compromise entire databases and business operations. Understanding, testing, and defending against SQLi is fundamental to web application security.