SQL Injection

Behind most web applications sits a database — an organised store of the application's data. User accounts, posts, orders: all of it lives in tables, which are just grids. A users table might look like this:

The application talks to the database in a language called SQL (Structured Query Language). SQL reads a lot like English. To find a user you would write:

SELECT * FROM users WHERE name = 'alice'

"Select all columns from the users table where the name is alice." The database runs that sentence and hands back the matching row. Simple and powerful — and the power is exactly the problem, because if an attacker can influence that sentence, they can make the database do things the developer never intended.

Here is how a careless login builds its query. The developer takes the username and password from the form and glues them straight into the SQL:

$sql = "SELECT * FROM users
        WHERE name = '" . $username . "'
        AND pass = '" . $password . "'";

If you log in as alice with password secret, the finished sentence is exactly what you would hope:

SELECT * FROM users WHERE name = 'alice' AND pass = 'secret'

Notice *where* your input sits: inside the single quotes. As long as it stays inside those quotes, it is just a value — data. The quotes are the walls of the "data" box. The whole attack is about climbing over that wall.

What happens if your username is not a name at all, but contains a single quote?

Say you type alice' into the username box. The server glues it in and the sentence becomes:

SELECT * FROM users WHERE name = 'alice'' AND pass = '...'

That stray quote lands in the middle of the sentence and the database can no longer make sense of it — you will usually get a database error, often surfaced as a 500 status. That error is the discovery moment. A single quote breaking the page is the classic sign that your input is reaching the query unescaped — that the "data" box has a hole in its wall.

Pentesters call this first step "putting a quote in to see if it breaks." If it breaks, the input is not being kept safely inside its box, and you can probably rewrite the sentence. If it does not break, the application may be handling input properly — good for them, on to the next input for you.

Now we weaponise that hole. We will not just break the sentence — we will rewrite it so it always says "yes." Put this in the username box:

' OR '1'='1

Glue it into the query and read the result carefully:

SELECT * FROM users WHERE name = '' OR '1'='1' AND pass = '...'

Take it piece by piece:

• The opening ' closes the empty name value early — we have climbed out of the data box.
• OR '1'='1' adds a condition of our own. '1'='1' is always true. "Name is empty OR one equals one" — and one always equals one, so the whole condition is true for every row.
• The database happily returns a user, the application sees a returned row, thinks "credentials matched," and logs us in. We never knew a password.

That is login bypass: you did not guess a secret, you changed the question so the answer no longer depended on the secret. This is the canonical SQL injection, and understanding every character of it is worth more than memorising fifty payloads.

A beginner's instinct is to ban the quote character — strip out apostrophes, block the word OR. This is a blocklist, and it is a trap. Attackers have endless ways around it: different quoting, comments inside keywords, encoded characters, entirely different payloads for data that is a number rather than a string. You will always miss one. Trying to name every bad input is a game you lose eventually.

The real fix removes the whole class of bug. It is called a prepared statement (or parameterised query).

The idea is beautifully simple: send the sentence and the values to the database separately. First you send the query with a placeholder where the value goes:

SELECT * FROM users WHERE name = ?

Then you send the value — ' OR '1'='1 — as a *separate* parcel. Because the database received the sentence *first*, its structure is already locked in. The value arrives afterwards and can only ever fill the placeholder as data. There is no way for it to become part of the sentence, no matter what characters it contains. The data/code boundary is enforced by the database itself, not by you trying to sanitise cleverly.

In PHP with PDO that looks like:

$stmt = $pdo->prepare('SELECT * FROM users WHERE name = ?');
$stmt->execute([$username]);

Every mainstream language has the same tool. Use it for every query that touches user input, and SQL injection simply cannot happen there.

Submit the keys below to log this exercise.