Intro to SQL Injection

SQL injection happens when an application builds a SQL query from user input without keeping that input as data. If the input can close a quote or add a clause, it can change what the database is asked to do.

How it happens

A login form that concatenates strings looks like this in the backend:

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

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

With ordinary input the quotes stay paired. If the username is alice and the password is secret, the query is:

SELECT * FROM users WHERE username = 'alice' AND password = 'secret'

Each value sits between its own quotes. The AND still joins two real checks.

If the username is:

admin' OR '1'='1' --

the query becomes:

SELECT * FROM users WHERE username = 'admin' OR '1'='1' --' AND password = '...'

Read that WHERE left to right:

Because the OR side is always true, the WHERE matches without a correct password. The database returns a row — often the first user, or admin if that row exists. The application treats that row as a successful login.

In admin' OR '1'='1' --, the first ' is the boundary: it closes the username value, and the remaining characters are parsed as SQL syntax. The input changes the query itself, not merely the username being compared.

That payload fits this query shape. Other queries need a different close-quote, comment, or clause.

Parameterised queries

A parameterised query (prepared statement) sends the SQL and the values separately. The SQL is compiled first. The values are bound afterwards, as data. They never go through the SQL parser.

SQLite example

cursor.execute(
    "SELECT * FROM users WHERE username = ? AND password = ?",
    (username, password),
)

const statement = db.prepare(
  "SELECT * FROM users WHERE username = ? AND password = ?",
);
const user = statement.get(username, password);

? is a placeholder. SQLite fills it with the bound value. The quote characters are added by the database, not by string concatenation.

If username is admin' OR '1'='1' -- and password is x, the statement the database runs is still:

SELECT * FROM users WHERE username = ? AND password = ?

with two bound values:

The ' , OR, and -- are characters in a username. The database looks for a user whose name is that whole string. There is no extra OR, and the password check is still there.

Other database placeholders

Placeholder syntax depends on the driver:

# PostgreSQL
cursor.execute(
    "SELECT * FROM users WHERE username = %s AND password = %s",
    (username, password),
)

// PostgreSQL with node-postgres
const result = await client.query(
  "SELECT * FROM users WHERE username = $1 AND password = $2",
  [username, password],
);

ORMs and raw SQL

ORMs can handle parameter binding for you, but only when you use their value APIs. For example, the Django ORM keeps this value separate from the generated SQL:

User.objects.filter(username=username)

SQLAlchemy provides the same protection through bound parameters. An ORM does not make concatenated raw SQL safe. This Django example is still vulnerable:

User.objects.raw("SELECT * FROM users WHERE username = '" + username + "'")

When raw SQL is necessary, follow the ORM's parameter API rather than inserting the value into the SQL string.

Real password handling

The login query above is deliberately simplified to teach parameter binding. Real applications should store a password hash, fetch the user by username with a parameterised query, and verify the submitted password with a password-hashing function. They should not store or compare plaintext passwords in SQL.

Worked example

Start with a baseline request:

POST /login HTTP/1.1
Content-Type: application/x-www-form-urlencoded

username=admin&password=wrong

Record the status, response length, message, and whether the page redirects. Then change only the username:

POST /login HTTP/1.1
Content-Type: application/x-www-form-urlencoded

username=admin%27&password=wrong

%27 is a URL-encoded single quote. It does not have to produce a visible SQL error. The application may catch the error and return the same "invalid credentials" page.

If the behaviour is interesting, compare a condition that is true with the same condition made false:

admin' AND '1'='1' --
admin' AND '1'='2' --

Send both with the same password and session, then compare them with the baseline:

• If the true condition changes the response while the false condition matches the baseline, the added text is probably being parsed as part of the SQL WHERE clause. The true version allows a row to match; the false version prevents that match.
• If both look like the baseline failure, the test is inconclusive. The field may be safe, or these strings may not fit the query.
• If either request causes a server error, you found a broken code path, not proof of SQL injection.

Other SQL injection shapes

SQL injection does not always produce a login bypass, visible data, or a database error. When the query result is hidden, differences in page behaviour or response time can still reveal whether a condition was true; this is called blind SQL injection.

These are alternatives, not steps. Choose based on the query context and what changes in the response.

Common mistakes

• Jumping to a long payload list, so you cannot tell which part changed the response.
• Changing the username, password, cookies, and headers together instead of preserving a baseline.
• Treating one server error as proof of SQL injection without comparing another condition.
• Assuming an ORM is automatically safe while still passing it raw concatenated SQL.

Tools and resources

• PortSwigger SQL injection guide for query-context examples and testing techniques
• OWASP SQL Injection Prevention Cheat Sheet for parameterised-query guidance

Only practise against systems you own or are explicitly authorised to test, such as this lab.

Self-check

A quote still gives the same "invalid credentials" page. Safe?

Not necessarily. The app may just be hiding the error. Try one small boolean-shaped change and compare.

Next

Krusty Krab Time Clock