SQL Injection
SQL Injection (SQLi) is a code injection technique where an attacker inserts malicious SQL statements into application queries, potentially reading, modifying, or deleting database data. It is one of the oldest and most dangerous web vulnerabilities.
§ 1 Definition
SQL Injection occurs when user input is incorporated into SQL queries without proper sanitization or parameterization. An attacker can manipulate input fields (forms, URL parameters, headers) to alter the intended SQL command. This can allow reading arbitrary data from the database (including password hashes, credit card numbers), modifying or deleting records, escalating privileges, and in some cases executing commands on the database server. SQLi has been responsible for some of the largest data breaches in history.
§ 2 Types of SQL Injection
In-band SQLi: The attacker uses the same channel to inject and retrieve results. Classic error-based or UNION-based SQLi. Inferential (Blind) SQLi: The attacker sends payloads and observes the application's behavior (response timing, boolean responses) to infer data. Time-based and boolean-based blind SQLi. Out-of-band SQLi: The attacker uses a different channel (e.g., DNS or HTTP requests) to exfiltrate data when the database server can make network requests.
§ 3 Prevention
The primary defense is parameterized queries (prepared statements). Separating SQL logic from data prevents user input from being interpreted as SQL code. Use an ORM (Object-Relational Mapper) or parameterized queries provided by your database library. Input validation is secondary defense: whitelist allowed values where possible. Least privilege: the database user should have only the minimum permissions needed. WAF rules can detect and block SQLi patterns but should not be relied on as the sole defense.
§ 4 Real-World Impact
SQL injection was used in the 2009 Heartland Payment Systems breach (130 million credit cards exposed), the 2014 TalkTalk breach (over 150,000 customer records), and countless others. It remains in the OWASP Top 10 because too many applications still concatenate user input directly into SQL strings.
§ 5 Note
§ 6 Common questions
- Q. Does parameterized queries prevent all SQL injection?
- A. Yes, when used consistently for all queries. The database distinguishes between SQL code and data parameters. However, some stored procedures that build dynamic SQL are still vulnerable.
- Q. Can a WAF alone prevent SQL injection?
- A. No. WAFs can detect known attack patterns but can be bypassed with encoding, obfuscation, or novel payloads. Parameterized queries are the only reliable defense.
- Q. Is NoSQL immune to injection?
- A. No. NoSQL databases (MongoDB, CouchDB) are also susceptible to injection attacks, though the syntax differs. Always sanitize and parameterize NoSQL queries.
- SQL injection manipulates queries by injecting malicious SQL through user input.
- Parameterized queries (prepared statements) are the definitive defense.
- ORMs prevent SQLi when used correctly but are not a free pass.
- SQLi is in the OWASP Top 10 because it remains widespread and devastating.
Atomic Glue enforces parameterized queries in all projects, prefers ORMs with safe defaults, and runs automated SQLi scanning in CI/CD. Discuss your database architecture with us via get in touch.
Get in touchSQL Injection (SQLi) is a code injection technique where an attacker inserts malicious SQL statements into application queries, potentially reading, modifying, or deleting database data. It is one of the oldest and most dangerous web vulnerabilities.
Category: Security (also: Web Development)
Author: Atomic Glue Security Team
## Definition
SQL Injection occurs when user input is incorporated into SQL queries without proper sanitization or parameterization. An attacker can manipulate input fields (forms, URL parameters, headers) to alter the intended SQL command. This can allow reading arbitrary data from the database (including password hashes, credit card numbers), modifying or deleting records, escalating privileges, and in some cases executing commands on the database server. SQLi has been responsible for some of the largest data breaches in history.
## Types of SQL Injection
**In-band SQLi**: The attacker uses the same channel to inject and retrieve results. Classic error-based or UNION-based SQLi. **Inferential (Blind) SQLi**: The attacker sends payloads and observes the application's behavior (response timing, boolean responses) to infer data. Time-based and boolean-based blind SQLi. **Out-of-band SQLi**: The attacker uses a different channel (e.g., DNS or HTTP requests) to exfiltrate data when the database server can make network requests.
## Prevention
The primary defense is **parameterized queries (prepared statements)**. Separating SQL logic from data prevents user input from being interpreted as SQL code. Use an ORM (Object-Relational Mapper) or parameterized queries provided by your database library. **Input validation** is secondary defense: whitelist allowed values where possible. **Least privilege**: the database user should have only the minimum permissions needed. **WAF rules** can detect and block SQLi patterns but should not be relied on as the sole defense.
## Real-World Impact
SQL injection was used in the 2009 Heartland Payment Systems breach (130 million credit cards exposed), the 2014 TalkTalk breach (over 150,000 customer records), and countless others. It remains in the OWASP Top 10 because too many applications still concatenate user input directly into SQL strings.
## Note
ORMs (like Prisma, Sequelize, SQLAlchemy) prevent SQLi when used correctly, but raw queries through an ORM are still vulnerable. Stored procedures do not inherently prevent SQLi if they use dynamic SQL internally.
## Common questions
Q: Does parameterized queries prevent all SQL injection?
A: Yes, when used consistently for all queries. The database distinguishes between SQL code and data parameters. However, some stored procedures that build dynamic SQL are still vulnerable.
Q: Can a WAF alone prevent SQL injection?
A: No. WAFs can detect known attack patterns but can be bypassed with encoding, obfuscation, or novel payloads. Parameterized queries are the only reliable defense.
Q: Is NoSQL immune to injection?
A: No. NoSQL databases (MongoDB, CouchDB) are also susceptible to injection attacks, though the syntax differs. Always sanitize and parameterize NoSQL queries.
## Key takeaways
- SQL injection manipulates queries by injecting malicious SQL through user input.
- Parameterized queries (prepared statements) are the definitive defense.
- ORMs prevent SQLi when used correctly but are not a free pass.
- SQLi is in the OWASP Top 10 because it remains widespread and devastating.
## Related entries
- [XSS](atomicglue.co/glossary/xss)
- [WAF](atomicglue.co/glossary/waf)
- [Vulnerability Scanning](atomicglue.co/glossary/vulnerability-scanning)
Last updated December 2024. Permalink: atomicglue.co/glossary/sql-injection