How SQL injection exploits queries - Visual Walkthrough

Concept Flow - How SQL injection exploits queries

User Input Received

↓

Input Inserted into SQL Query

↓

Query Sent to Database

↓

Database Executes Query

↓

If Input is Malicious

Yes↓

SQL Injection Occurs

↓

Attacker Gains Unauthorized Access

↓

END

No↓

Query Executes Normally

↓

END

User input is added to a SQL query. If input is malicious, it changes query meaning, causing SQL injection and unauthorized access.

Execution Sample

SQL

user_input = "' OR '1'='1";
query = "SELECT * FROM users WHERE username = '" + user_input + "';";
-- Query sent to DB
-- DB executes query

This code shows how a malicious input changes a SQL query to always return true, causing SQL injection.

Execution Table

Step	User Input	Query Formed	Query Meaning	Result
1	' OR '1'='1	SELECT * FROM users WHERE username = '' OR '1'='1';	Returns all users because '1'='1' is always true	All user records returned (SQL Injection)
2	normalUser	SELECT * FROM users WHERE username = 'normalUser';	Returns user with username 'normalUser'	Only normalUser record returned
3	admin'; --	SELECT * FROM users WHERE username = 'admin'; --	Comments out rest, returns admin user	Admin user record returned (SQL Injection)
4		SELECT * FROM users WHERE username = '';	Returns no user (empty username)	No records returned
5	user123	SELECT * FROM users WHERE username = 'user123';	Returns user with username 'user123'	User123 record returned
6				Execution ends

💡 Execution stops after query is sent and database returns results.

Variable Tracker

Variable	Start	After 1	After 2	After 3	After 4	After 5	Final
user_input	null	' OR '1'='1	normalUser	admin'; --		user123	user123
query	null	SELECT * FROM users WHERE username = '' OR '1'='1';	SELECT * FROM users WHERE username = 'normalUser';	SELECT * FROM users WHERE username = 'admin'; --	SELECT * FROM users WHERE username = '';	SELECT * FROM users WHERE username = 'user123';	SELECT * FROM users WHERE username = 'user123';

Key Moments - 3 Insights

Why does the query return all users when input is "' OR '1'='1"?

Because the input closes the username string and adds OR '1'='1', which is always true, so the WHERE clause matches all rows (see execution_table step 1).

How does the input "admin'; --" change the query?

It closes the username string and adds a comment marker -- which ignores the rest of the query, effectively returning the admin user (see execution_table step 3).

Why does an empty input return no records?

Because the query becomes WHERE username = '', which matches no user (see execution_table step 4).

Visual Quiz - 3 Questions

Look at the execution_table at step 1, what does the query return?

A No records

B All user records

C Only admin user

D Syntax error

💡 Hint

Check the 'Result' column at step 1 in execution_table.

At which step does the input use SQL comment to change the query?

A Step 3

B Step 2

C Step 4

D Step 5

💡 Hint

Look for input containing '--' in execution_table.

If user_input is empty, what is the query result?

A Returns all users

B Returns admin user

C Returns no users

D Causes error

💡 Hint

See execution_table step 4 for empty input.

Concept Snapshot

SQL injection happens when user input is added directly to a query.
Malicious input can change query logic.
Example: input "' OR '1'='1" makes WHERE always true.
This returns all rows, bypassing security.
Always use parameterized queries to prevent injection.

Full Transcript

This visual execution shows how SQL injection exploits queries by inserting malicious user input. The input is added directly into the SQL query string. For example, input like "' OR '1'='1" changes the WHERE clause to always be true, returning all user records. Another input "admin'; --" uses SQL comment to ignore the rest of the query and return the admin user. Empty input returns no records. The execution table traces each step showing user input, formed query, meaning, and result. Variable tracker shows how user_input and query change each step. Key moments explain why certain inputs cause injection. The quiz tests understanding of these steps. The snapshot reminds to use parameterized queries to avoid this risk.

Practice

1. What is the main risk of SQL injection attacks on a database?

easy

A. Slower query performance

B. Unauthorized access to or manipulation of data

C. Syntax errors in SQL queries

D. Increased storage space usage

Solution

1. Step 1: Understand what SQL injection does

   SQL injection allows attackers to insert malicious SQL code into queries to manipulate the database.

2. Step 2: Identify the main consequence

   This manipulation can lead to unauthorized access or changes to data, which is a serious security risk.

3. Final Answer:

   Unauthorized access to or manipulation of data -> Option B

4. Quick Check:

   SQL injection = Unauthorized data access [OK]

Hint: SQL injection lets attackers access or change data illegally [OK]

Common Mistakes:

• Confusing SQL injection with performance issues
• Thinking it only causes syntax errors
• Assuming it increases storage use

2. Which of the following SQL query snippets is vulnerable to SQL injection if user input is not sanitized?
SELECT * FROM users WHERE username = '" + userInput + "';

easy

A. SELECT * FROM users WHERE username = '" + userInput + "';

B. SELECT * FROM users WHERE username = ?;

C. SELECT * FROM users WHERE username = 'admin';

D. SELECT * FROM users WHERE username = 'admin' AND password = 'pass';

Solution

1. Step 1: Identify how user input is used

   The query concatenates userInput directly into the SQL string without sanitization.

2. Step 2: Recognize vulnerability

   This direct insertion allows attackers to inject malicious SQL code, making it vulnerable.

3. Final Answer:

   SELECT * FROM users WHERE username = '" + userInput + "'; -> Option A

4. Quick Check:

   Direct input concatenation = Vulnerable [OK]

Hint: Directly adding user input to query string is unsafe [OK]

Common Mistakes:

• Choosing parameterized queries as vulnerable
• Confusing safe hardcoded queries with vulnerable ones
• Ignoring the role of input sanitization

3. Given the vulnerable query:
SELECT * FROM users WHERE username = '" + userInput + "';
If userInput is admin' OR '1'='1, what will the query become and what is the likely result?

medium

A. Syntax error due to unmatched quotes

B. SELECT * FROM users WHERE username = 'admin OR 1=1'; -- Returns no users

C. SELECT * FROM users WHERE username = 'admin'; -- Returns only admin user

D. SELECT * FROM users WHERE username = 'admin' OR '1'='1'; -- Returns all users

Solution

1. Step 1: Substitute userInput into the query

   The query becomes: SELECT * FROM users WHERE username = 'admin' OR '1'='1';

2. Step 2: Understand the effect of OR '1'='1'

   The condition '1'='1' is always true, so the WHERE clause matches all rows.

3. Final Answer:

   SELECT * FROM users WHERE username = 'admin' OR '1'='1'; -- Returns all users -> Option D

4. Quick Check:

   Injected OR '1'='1' returns all rows [OK]

Hint: OR '1'='1' always true returns all rows [OK]

Common Mistakes:

• Thinking it causes syntax error
• Assuming it returns only admin user
• Misreading the injected condition

4. You have this vulnerable SQL query in your code:
query = "SELECT * FROM users WHERE username = '" + userInput + "';"
Which fix correctly prevents SQL injection?

medium

A. Remove the WHERE clause entirely

B. Escape single quotes in userInput manually

C. Use parameterized queries or prepared statements

D. Convert userInput to uppercase before using

Solution

1. Step 1: Identify secure coding practice

   Parameterized queries separate code from data, preventing injection.

2. Step 2: Evaluate other options

   Manual escaping is error-prone, removing WHERE breaks logic, uppercase conversion doesn't prevent injection.

3. Final Answer:

   Use parameterized queries or prepared statements -> Option C

4. Quick Check:

   Parameterized queries = Safe from injection [OK]

Hint: Always use parameterized queries to stop injection [OK]

Common Mistakes:

• Relying on manual escaping only
• Removing query conditions instead of fixing
• Thinking input case changes prevent injection

5. Consider a login system using this vulnerable query:
SELECT * FROM users WHERE username = '" + userInput + "' AND password = '" + passInput + "';
If an attacker inputs admin' -- as username and anything as password, what happens and why?

hard

A. Login succeeds without password check because -- comments out rest

B. Login fails due to syntax error from unmatched quotes

C. Login succeeds only if password matches exactly

D. Login fails because input is rejected by the system

Solution

1. Step 1: Substitute attacker input into query

   The query becomes: SELECT * FROM users WHERE username = 'admin' --' AND password = 'anything';

2. Step 2: Understand effect of -- comment

   The -- makes the rest of the query a comment, so password check is ignored.

3. Step 3: Result of query

   The query checks only username = 'admin', allowing login without password.

4. Final Answer:

   Login succeeds without password check because -- comments out rest -> Option A

5. Quick Check:

   -- comments out password check = Login bypass [OK]

Hint: SQL comment -- skips password check for login bypass [OK]

Common Mistakes:

• Assuming syntax error occurs
• Thinking password is still checked
• Believing input is blocked automatically