SQL injection (SQLi) happens when user input is concatenated into a database query, letting an attacker change what the query does - read data, bypass auth, or dump the whole database.
The core bug
"SELECT * FROM users WHERE name = '" + input + "'" - if input is ' OR '1'='1, the query returns every row. That's the whole idea: data becomes code.
Flavors
- In-band - results come straight back in the response (error-based, UNION-based).
- Blind - no visible output; the attacker infers data from true/false responses (boolean-based) or response delays (time-based, e.g.
SLEEP(5)). - Out-of-band - the DB makes a DNS/HTTP callback carrying stolen data.
Detect it
- WAF/IDS alerts on SQL meta-characters and patterns (
UNION SELECT,SLEEP(,' OR '). - App logs showing DB errors or abnormally large result sets.
- The DB service account doing something it never normally does (mass reads, new tables).
Prevent it (the real fix)
- Parameterized queries / prepared statements - the fix. Input is bound as data, never parsed as SQL.
- Least-privilege DB accounts so a successful injection can't read everything.
- Input validation + an ORM as defense in depth (not a substitute for parameterization).
Test with sqlmap before someone else does - but the durable fix is always: never build queries by string concatenation.