SQL injection in plain English
Almost every web application stores its data in a database: customer accounts, orders, prices. To retrieve data, the application sends queries in the database language SQL (Structured Query Language), for example: “Show all orders from customer 4711.”
Imagine a conscientious but naive archivist. He receives slips of paper that read “Please pull the file for: _.” Normally, a name goes in the blank. If someone writes “Miller – and all the other files, too” instead, the archivist does both.
He doesn’t distinguish between the name he’s supposed to look up and an additional instruction. That’s exactly what happens in SQL injection: the application inserts input into its database query without checking it. The database then treats the injected characters as part of the command.
How SQL injection works
A simplified example illustrates the principle:
- The application builds a query: A login page inserts the entered username directly into an SQL command, such as
SELECT * FROM users WHERE name = 'INPUT'. - The attacker manipulates the input: Instead of a name, they enter something like
' OR '1'='1. The single quote ends the text early, and the rest becomes part of the command. - The condition is always true: The query now essentially says: “Return all users whose name is empty – or for whom 1 equals 1.” Because 1 always equals 1, the database returns every single entry.
- The consequences: Depending on the application, the attacker can bypass logins, read entire tables, and modify or delete data.
It’s not just visible form fields that are vulnerable – URL parameters, cookies, and API requests are, too. The application doesn’t always display the result directly. In what’s known as blind SQL injection, attackers piece the data together step by step from indirect clues, such as the server’s response time.
In the worst case, the database can even be used to execute commands on the server. The SQL injection then turns into remote code execution.
A practical example
A specialist tool retailer runs its own online shop. During a penetration test, the search function stands out: a single quote character in the search term triggers a database error message. Further tests show that the entire customer table could be queried via the search field – including names, addresses, and the stored password hashes. Hashes are passwords converted into a form that can’t be reversed. Weak passwords, however, can often be recovered from them by trying out huge numbers of candidates.
The testers immediately report the finding to the agreed contact. The developers switch the search to parameterized queries, the application gets a database account with minimal privileges, and error messages no longer reveal technical details. A retest confirms that the vulnerability has been closed.
Why does this matter for businesses?
SQL injection has been known for many years – and yet it isn’t a thing of the past. Injection vulnerabilities have long been part of the OWASP Top 10, the best-known overview of the most critical security risks for web applications. Automated tools scan the internet specifically for such flaws.
The consequences can be significant. If personal data falls into the wrong hands, companies generally have to report the data breach to the competent supervisory authority under Art. 33 GDPR without undue delay and, where feasible, within 72 hours. On top of that come a loss of customer trust and the effort of dealing with the aftermath.
How to protect your organization
- Parameterized queries: Prepared statements cleanly separate commands from data. Input is then always treated purely as data – the most effective countermeasure.
- Use frameworks correctly: Modern frameworks – ready-made programming toolkits – usually provide protection automatically. Be careful with hand-built queries that bypass this protection.
- Validate input: Allow only what’s expected – for example, nothing but digits in a customer number field.
- Least privilege: The application’s database account should be allowed to do only what it really needs to.
- Neutral error messages: Users see a generic message; technical details go into the log.
- Additional layer of protection: A web application firewall can intercept attacks, but it’s no substitute for secure code.
- Test regularly: Automated testing of the source code (SAST) or the running application (DAST), along with manual penetration tests, uncovers vulnerabilities before attackers find them.
How Rootsektor can help
In a web application penetration test, we manually test your applications and online shops for injection flaws and other vulnerabilities – guided by the OWASP Testing Guide. We cover APIs in an API penetration test. We report critical vulnerabilities immediately – during the test, by phone or email to the agreed contact person. The retest of remediated vulnerabilities is free of charge.