SQL injection testing in Testing Fundamentals - Test Execution Trace

Test Overview

This test checks if the login form is vulnerable to SQL injection by entering a malicious input. It verifies that the system does not allow unauthorized access using SQL injection.

Test Code - Selenium with Python unittest

Testing Fundamentals

import unittest
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

class TestSQLInjection(unittest.TestCase):
    def setUp(self):
        self.driver = webdriver.Chrome()
        self.driver.get('http://example.com/login')

    def test_sql_injection_login(self):
        driver = self.driver
        # Find username and password fields
        username_field = WebDriverWait(driver, 10).until(
            EC.presence_of_element_located((By.ID, 'username'))
        )
        password_field = driver.find_element(By.ID, 'password')

        # Enter SQL injection string
        username_field.clear()
        username_field.send_keys("' OR '1'='1'")
        password_field.clear()
        password_field.send_keys("anything")

        # Click login button
        login_button = driver.find_element(By.ID, 'login-btn')
        login_button.click()

        # Wait for response and check for login failure message
        error_message = WebDriverWait(driver, 10).until(
            EC.presence_of_element_located((By.ID, 'login-error'))
        )

        # Assert that error message is displayed, meaning injection failed
        self.assertTrue(error_message.is_displayed(), "SQL Injection succeeded, vulnerability found")

    def tearDown(self):
        self.driver.quit()

if __name__ == '__main__':
    unittest.main()

Execution Trace - 9 Steps

Step	Action	System State	Assertion	Result
1	Test starts and opens Chrome browser	Browser opened at 'http://example.com/login' showing login form with username, password fields and login button	—	PASS
2	Find username input field by ID 'username'	Username input field is present and ready for input	WebDriverWait confirms presence of username field	PASS
3	Find password input field by ID 'password'	Password input field is present and ready for input	—	PASS
4	Enter SQL injection string "' OR '1'='1'" into username field	Username field contains malicious input	—	PASS
5	Enter 'anything' into password field	Password field contains input	—	PASS
6	Find and click login button by ID 'login-btn'	Login button clicked, form submitted	—	PASS
7	Wait for error message element with ID 'login-error' to appear	Error message displayed on page indicating login failure	Check that error message is displayed to confirm login failed	PASS
8	Assert error message is displayed to verify SQL injection did not bypass login	Test confirms login failure message is visible	assertTrue(error_message.is_displayed())	PASS
9	Close browser and end test	Browser closed	—	PASS

Failure Scenario

Failing Condition: The login form is vulnerable and accepts the SQL injection input, allowing unauthorized access.

Execution Trace Quiz - 3 Questions

What does the test verify after clicking the login button with SQL injection input?

A That the login button is disabled

B That the user is logged in successfully

C That an error message is displayed indicating login failure

D That the password field is cleared

Key Result

Always verify that input fields are protected against SQL injection by checking that malicious inputs do not bypass authentication and that proper error messages appear.

Practice

1. What is the main goal of SQL injection testing in software testing?

easy

A. To check if user input can change database queries and cause harm

B. To improve the speed of SQL queries

C. To test the user interface design

D. To verify the database schema structure

Solution

1. Step 1: Understand SQL injection testing purpose

   SQL injection testing checks if user inputs can alter SQL queries in harmful ways.

2. Step 2: Compare options with testing goal

   Only To check if user input can change database queries and cause harm matches the goal of detecting harmful input effects on queries.

3. Final Answer:

   To check if user input can change database queries and cause harm -> Option A

4. Quick Check:

   SQL injection testing = check harmful input [OK]

Hint: Focus on input impact on queries, not UI or speed [OK]

Common Mistakes:

• Confusing SQL injection testing with performance testing
• Thinking it tests UI or database design
• Ignoring the role of user input in testing

2. Which of the following is a correct example of an input used in SQL injection testing?

easy

A. DROP TABLE users;

B. SELECT * FROM users

C. INSERT INTO users VALUES ('admin')

D. ' OR '1'='1

Solution

1. Step 1: Identify typical SQL injection input

   Inputs like ' OR '1'='1 try to change query logic to always true.

2. Step 2: Check other options

   Options A, B, and D are full SQL commands, not typical injection inputs entered by users.

3. Final Answer:

   ' OR '1'='1 -> Option D

4. Quick Check:

   Injection input = ' OR '1'='1 [OK]

Hint: Look for input that changes query logic with OR and quotes [OK]

Common Mistakes:

• Choosing full SQL commands as injection input
• Not recognizing the use of quotes and OR in injection
• Confusing injection input with SQL statements

3. Consider this SQL query in a login system:

SELECT * FROM users WHERE username = '{input}' AND password = '{input}';

If the input for username is admin and for password is ' OR '1'='1, what will happen?

medium

A. The query will return no results

B. The query will cause a syntax error

C. The query will return all users, bypassing password check

D. The query will only return the admin user

Solution

1. Step 1: Substitute inputs into query

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

2. Step 2: Analyze the WHERE clause logic

   The OR '1'='1' makes the password condition always true, so the query returns all users matching username or always true condition.

3. Final Answer:

   The query will return all users, bypassing password check -> Option C

4. Quick Check:

   Injection bypasses password = returns all users [OK]

Hint: OR '1'='1' makes condition always true, bypassing checks [OK]

Common Mistakes:

• Ignoring OR logic and thinking password check still applies
• Assuming syntax error without checking quotes
• Thinking only admin user is returned

4. You have this vulnerable SQL query:

query = "SELECT * FROM products WHERE id = '" + user_input + "'";

Which fix will prevent SQL injection?

medium

A. Add more single quotes around user_input

B. Use parameterized queries or prepared statements

C. Remove the WHERE clause

D. Convert user_input to uppercase

Solution

1. Step 1: Identify the vulnerability

   Concatenating user input directly into query allows injection.

2. Step 2: Choose the correct fix

   Using parameterized queries safely separates input from code, preventing injection.

3. Final Answer:

   Use parameterized queries or prepared statements -> Option B

4. Quick Check:

   Parameterized queries prevent injection [OK]

Hint: Never concatenate input; use parameters instead [OK]

Common Mistakes:

• Thinking adding quotes fixes injection
• Removing WHERE clause breaks functionality
• Changing case does not prevent injection

5. A web app uses this query to search users:

SELECT * FROM users WHERE name LIKE '%{input}%';

Which input is the safest to test for SQL injection without causing errors or data loss?

hard

A. normaluser

B. admin'; DROP TABLE users;--

C. '; EXEC xp_cmdshell('dir');--

D. ' OR '1'='1

Solution

1. Step 1: Understand safe testing input

   Safe input should not break query syntax or cause harmful commands.

2. Step 2: Evaluate options

   Options A, B, and C contain injection attempts or dangerous commands; only D is a normal string safe for testing.

3. Final Answer:

   normaluser -> Option A

4. Quick Check:

   Safe test input = normaluser [OK]

Hint: Use normal strings to test safely before injection attempts [OK]

Common Mistakes:

• Using dangerous inputs that cause errors or data loss
• Assuming all injection inputs are safe to test
• Not understanding query context with LIKE and wildcards