How SQL injection exploits queries - Interactive Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to select user data by username safely.

SQL

SELECT * FROM users WHERE username = '[1]';

Drag options to blanks, or click blank then click option'

Apassword

Badmin' OR '1'='1

Cadmin

Dguest

Attempts:

3 left

💡 Hint

Common Mistakes

Using input like 'admin' OR '1'='1' which changes the query meaning.

The username should be a simple string like 'admin' to avoid SQL injection.

2fill in blank

medium

Complete the code to prevent SQL injection by using parameter placeholders.

SQL

SELECT * FROM users WHERE username = [1];

Drag options to blanks, or click blank then click option'

A'admin' OR '1'='1'

Busername

Cadmin

D?

Attempts:

3 left

💡 Hint

Common Mistakes

Putting user input directly into the query string.

Using a parameter placeholder like '?' helps prevent SQL injection by separating code from data.

3fill in blank

hard

Fix the error in the query that allows SQL injection.

SQL

SELECT * FROM users WHERE username = '[1]';

Drag options to blanks, or click blank then click option'

Aadmin

Badmin' OR '1'='1

Cadmin'; DROP TABLE users; --

Dguest

Attempts:

3 left

💡 Hint

Common Mistakes

Using input that ends the string and adds malicious SQL.

Only a simple username like 'admin' avoids injection. The others inject extra SQL commands.

4fill in blank

hard

Fill both blanks to safely check username and password using parameters.

SQL

SELECT * FROM users WHERE username = [1] AND password = [2];

Drag options to blanks, or click blank then click option'

A?

B' OR '1'='1

C:password

Dadmin

Attempts:

3 left

💡 Hint

Common Mistakes

Putting raw input directly into the query string.

Use placeholders like '?' and named parameters like ':password' to prevent injection.

5fill in blank

hard

Fill all three blanks to create a safe query that filters users by role and status.

SQL

SELECT * FROM users WHERE role = [1] AND status = [2] AND active = [3];

Drag options to blanks, or click blank then click option'

A?

B'admin'

C1

DTRUE

Attempts:

3 left

💡 Hint

Common Mistakes

Putting user input directly without placeholders.

Using unquoted strings for string values.

Use a safe string for role, a placeholder for status, and a boolean TRUE for active.

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