SQL Injection.

SQL injection (SQLi) exploits applications that concatenate untrusted input into SQL statements instead of using parameterised queries. By injecting quotes, comments, or UNION clauses, an attacker rewrites the intended query to dump tables, bypass authentication, escalate privileges, or run database commands. Variants include classic in-band, error-based, blind boolean/time-based (inferring data one bit at a time from responses or response delays), and second-order, where stored input fires when later reused.

SQLi is decades old yet still devastating. CVE-2023-34362, a zero-day SQL injection in Progress MOVEit Transfer, was exploited from late May 2023 by the Cl0p ransomware group: unauthenticated attackers injected SQL to deploy the LEMURLOOT web shell and exfiltrate database contents, cascading into thousands of downstream organisations. The 2015 TalkTalk breach, which exposed roughly 157,000 customer records, was likewise a SQL injection against a legacy web page. SQLi sits under OWASP Top 10 A03:2021 (Injection).

The primary defence is parameterised queries / prepared statements, which separate code from data so input can never alter query structure. Reinforce with ORM frameworks used safely, allow-list input validation, least-privilege database accounts (no DBA rights for app logins), stored-procedure hygiene, and a WAF as defence-in-depth. Manual escaping alone is fragile and discouraged.

flowchart TD
  U[Untrusted input] --> C{How is the query built?}
  C -->|String concatenation| I["' OR 1=1 -- injected into SQL"]
  I --> DB[(Database executes attacker SQL)]
  DB --> X[Data dump / auth bypass]
  C -->|Parameterised query| S[Input bound as data, not code]
  S --> OK[Query structure preserved — safe]