SQL Injection: How One Quote Character Breaks a Database

In 1998, a researcher named Rain Forest Puppy published a paper describing a technique where you could manipulate a database query by injecting SQL syntax through user input. Over 25 years later, SQL injection is still the number one cause of data breaches involving web applications. That should tell you something.

This isn't a list of tools or a career tips post. This is a precise explanation of exactly what happens when you inject SQL — from the character you type to the database row that comes back.

How a login form actually works under the hood

When you type your username and password into a login form, the backend runs a database query something like this:

SELECT * FROM users
WHERE username = 'alice'
AND password = 'hunter2';

If that query returns a row, you're in. Simple enough. The problem is that most applications build that query by gluing your input directly into the SQL string:

query = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'";

The database has no idea where your input ends and the SQL begins. They're the same string.

What one quote character does

Type this as your username: admin'--

The query becomes:

SELECT * FROM users
WHERE username = 'admin'--' AND password = 'anything';

In SQL, -- is a comment. Everything after it is ignored. So the password check disappears. The query now just checks if a user named admin exists — and logs you in as them if it does.

No password required.

Going further: pulling data you shouldn't see

Authentication bypass is the obvious trick, but it's not the most dangerous. Once you can inject SQL, you can use UNION to append your own query and retrieve data from any table.

' UNION SELECT username, password, null FROM users--

That returns every username and password hash in the database alongside whatever the original query would have returned. From one input field.

With blind SQL injection — where the app doesn't show you query output — attackers use boolean conditions or time delays (SLEEP(5)) to extract data one bit at a time. Tools like sqlmap automate this entirely.

Why it's still everywhere

• —Legacy codebases — code written before ORMs were standard that nobody wants to touch
• —Frameworks used wrong — parameterised queries exist but developers bypass them for "convenience"
• —Third-party components — plugins, libraries, and integrations nobody audited
• —APIs — backend endpoints that aren't exposed in the UI but accept the same raw input

The actual fix

Parameterised queries (also called prepared statements). Your input is passed as a parameter separate from the SQL structure — the database treats it as data, not code, no matter what it contains.

// Vulnerable
query = "SELECT * FROM users WHERE username = '" + username + "'";

// Safe
stmt = db.prepare("SELECT * FROM users WHERE username = ?");
stmt.execute([username]);

The input admin'-- now searches literally for a user whose name is admin'--. The quote is data. It never touches the SQL parser.

How to find SQLi as a tester

The manual approach: add a single quote to every input field and look for database errors, unexpected behaviour, or a change in the response. A generic "internal server error" after a quote is a strong signal.

From there you determine the database type (MySQL, PostgreSQL, MSSQL — each has syntax differences), figure out the number of columns in the query using ORDER BY, then craft your UNION to extract what you need.

The automated approach is sqlmap. Point it at a URL with a parameter, let it run. It handles detection, exploitation, and extraction automatically.