SQL injection testing in Testing Fundamentals - Build an Automation Script

Test login form for SQL injection vulnerability

Preconditions (2)

Step 1: Open the login page URL in a browser

Step 2: In the username field, enter the string: ' OR '1'='1

Step 3: In the password field, enter any value, e.g., 'password'

Step 4: Click the Login button

Step 5: Observe the result

✅ Expected Result: The login should fail and show an error message. The application must not allow login with the SQL injection string.

Automation Requirements - Selenium with Python

Assertions Needed:

Verify that the login is unsuccessful

Verify that an error message is displayed indicating invalid credentials or login failure

Verify that the URL does not change to the dashboard or authenticated page

Best Practices:

Use explicit waits to wait for elements to be visible or clickable

Use meaningful locators like By.ID or By.NAME instead of brittle XPath

Use assertions to check page content and URL

Handle exceptions gracefully to avoid test crashes

Automated Solution

Testing Fundamentals

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
import unittest

class TestSQLInjection(unittest.TestCase):
    def setUp(self):
        self.driver = webdriver.Chrome()
        self.driver.get('https://example.com/login')  # Replace with actual login URL
        self.wait = WebDriverWait(self.driver, 10)

    def test_sql_injection_login(self):
        driver = self.driver
        wait = self.wait

        # Locate username field and enter SQL injection string
        username_field = wait.until(EC.visibility_of_element_located((By.ID, 'username')))
        username_field.clear()
        username_field.send_keys("' OR '1'='1")

        # Locate password field and enter any password
        password_field = driver.find_element(By.ID, 'password')
        password_field.clear()
        password_field.send_keys('password')

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

        # Wait for error message or login failure indication
        error_message = wait.until(EC.visibility_of_element_located((By.ID, 'errorMsg')))

        # Assert error message is displayed
        self.assertTrue(error_message.is_displayed(), 'Error message should be displayed')

        # Assert URL does not contain dashboard path
        current_url = driver.current_url
        self.assertNotIn('/dashboard', current_url, 'Should not navigate to dashboard on SQL injection')

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

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

This test script uses Selenium with Python's unittest framework.

setUp: Opens the browser and navigates to the login page.

test_sql_injection_login: Enters a classic SQL injection string in the username field and a dummy password, then clicks login.

It waits explicitly for the error message element to appear, ensuring the page has responded.

Assertions check that the error message is visible and the URL does not change to the dashboard, confirming login failure.

tearDown: Closes the browser after the test.

Explicit waits and meaningful locators (By.ID) are used for reliability and maintainability.

Common Mistakes - 4 Pitfalls

Using time.sleep() instead of explicit waits

Using brittle XPath selectors like absolute paths

Not verifying the error message or page URL after login attempt

Hardcoding URLs or credentials inside the test without flexibility

Bonus Challenge

Now add data-driven testing with 3 different SQL injection strings in the username field

Show Hint

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