SQL injection: principles and impact

Imagine a waiter who writes your order on a slip and passes it to the kitchen exactly as you spoke it. If you say “one soup, and also give me the cash register”, and the kitchen obeys, you have a problem. SQL injection is the digital version of this: an application mixes user input with database commands, and the database cannot tell the difference between the two.

A quick reminder about SQL and databases

Most web applications store their data (users, products, orders) in a relational database. They talk to it using SQL (Structured Query Language). A query to look up a user might look like this:

SELECT id, name, email FROM users WHERE id = 42;

Read it aloud: “give me the id, name and email from the users table where the id is 42”. The application does not know in advance which identifier the user will ask for, so it builds the query dynamically, inserting a value coming from the request.

Where the flaw comes from

The naive way to build the query is to concatenate the user’s value into the text of the query. Here is a deliberately vulnerable example in PHP, the kind of code that appears in training applications:

$id = $_GET['id'];
$query = "SELECT name, email FROM users WHERE id = '" . $id . "'";
$result = mysqli_query($connection, $query);

If a visitor sends id=42, the final query is the one we expect. But the program never checks what the value contains. A value that includes characters with special meaning in SQL, such as a quote that closes the string, can change the structure of the query itself. The input stops being data and becomes part of the command.

That is the whole concept: data crossing into code. The database receives one single text and has no way to know which part the developer wrote and which part the visitor supplied.

What an attacker could achieve

The impact depends on the application and on the permissions of the database account it uses, but SQL injection is considered one of the most serious web flaws because it can touch the three pillars of security:

Pillar	Possible impact
Confidentiality	Reading data the user should not see: other customers, password hashes, internal tables
Integrity	Modifying or deleting records, changing prices or roles
Availability	Heavy queries that slow or crash the service, destroyed data
Authentication bypass	Logging in without valid credentials when the login query is vulnerable
Wider compromise	On badly configured servers, interacting with the underlying system

This is why OWASP groups it under the Injection category of the Top 10, and why many well-known data breaches in history started with it. The flaw is old and well understood, yet it keeps appearing in code written without care.

Types of SQL injection

Testers classify the variants by how the result becomes visible:

• In-band (error-based and union-based): the result or an error message appears directly in the application’s response. This is the easiest to notice and teaches the principle best.
• Blind: the application shows no data and no error, but its behaviour (a page appearing or not, a measurable delay) reveals the answer to yes/no questions. It is slower to exploit but equally dangerous.
• Out-of-band: the database is made to send information through another channel, such as a network request. It is used when the other types are impossible.

You only need to recognise these families for now. The most important message is that a vulnerability exists even when nothing visible happens: the absence of error messages does not prove the absence of injection.

Where to look for injection points

Anywhere the application uses a value from the client to build a database query. Revisit your inventory from chapter 1:

• Search boxes and filters.
• Login forms and registration forms.
• Numeric identifiers in URLs and query strings (?id=, /product/12).
• Sorting parameters such as sort=price, which are often inserted into queries without protection.
• Cookies and HTTP headers that the application logs or looks up.
• Values in JSON bodies sent to APIs.

Keep in mind that the application might place your value in different parts of the query: inside a quoted string, as a bare number, or in an ORDER BY clause. Each position behaves differently, which is why testers always observe carefully before drawing conclusions.

Why it still happens

• Developers under time pressure write the quick concatenation, “just for this one query”.
• Input validation is attempted instead of parameterised queries, and is incomplete.
• Older code, copied examples and custom-built query helpers perpetuate the pattern.
• Developers assume an input field “can only contain a number” because of the interface, forgetting that the browser can be bypassed with a proxy (chapter 1).

The tester’s mindset

In a professional engagement, you do not extract an entire database to prove the flaw. You show the minimum proof: that you can change the behaviour of the query in a controlled, harmless way, and you stop there. Reading a single row of non-sensitive data, or demonstrating a true/false difference in the response, is enough for the report. Dumping customer records creates a personal-data problem for everyone involved, including you.

How you will recognise it in your lab

Typical signals that an input might be reaching a database unsafely are:

• A special character causes a database error message to appear, mentioning SQL syntax.
• The page gives a generic server error (status 500) only for certain inputs.
• The response changes when you modify the logical meaning of the value, in a predictable way.
• The response time changes in a consistent way for specific inputs.

The following lesson walks you through these signals in DVWA or an equivalent lab.

Your turn: spot the danger in code

Here are three code snippets. For each one, say whether you would flag it as vulnerable to SQL injection, and why.

// A
$q = "SELECT * FROM products WHERE category = '" . $_GET['cat'] . "'";

// B
$stmt = $pdo->prepare("SELECT * FROM products WHERE category = :cat");
$stmt->execute([':cat' => $_GET['cat']]);

// C
$q = "SELECT * FROM orders ORDER BY " . $_GET['sort'];

See a solution

• A is vulnerable. The category value is concatenated directly into the query text.
• B is safe against injection. The query structure is sent first with a placeholder, and the value is sent separately as data, so it can never change the structure.
• C is vulnerable. The sort parameter is inserted without any protection. It is a good reminder that injection is not limited to WHERE clauses. The correct approach is to map the value against a fixed list of allowed column names.

Write these three lines in your notebook with the verdict; you will use them in lesson 4 as a before and after.

Now let us observe all this in a controlled setting.