SQL injection testing in Testing Fundamentals - Framework Patterns

Framework Mode - SQL injection testing

Folder Structure

sql-injection-testing/
├── tests/
│   ├── injection_tests.sql
│   ├── test_login_injection.sql
│   └── test_search_injection.sql
├── utils/
│   ├── db_connection.py
│   └── payloads.py
├── config/
│   ├── environments.yaml
│   └── credentials.yaml
├── reports/
│   └── latest_report.html
└── README.md

Test Framework Layers

• Test Scripts: SQL scripts or automated test scripts that run injection payloads against input fields or queries.
• Utility Layer: Helper functions for database connection, executing queries safely, and managing injection payloads.
• Configuration Layer: Holds environment details like database URLs, user credentials, and test parameters.
• Reporting Layer: Collects test results, logs, and generates readable reports for analysis.

Configuration Patterns

• Environment Files: Use YAML or JSON files to store database connection strings for dev, test, and prod environments.
• Credentials Management: Store usernames and passwords securely, avoid hardcoding in test scripts.
• Payload Management: Maintain a centralized list of SQL injection payloads in a separate file for easy updates.
• Parameterization: Use parameterized queries in utilities to prevent accidental injection during testing.

Test Reporting and CI/CD Integration

• Generate HTML or XML reports summarizing which injection tests passed or failed.
• Include detailed logs showing the payload used, query executed, and database response.
• Integrate tests into CI/CD pipelines to run automatically on code changes.
• Fail builds if critical injection vulnerabilities are detected.

Best Practices

• Use Parameterized Queries: Always test that the application uses parameterized queries to prevent injection.
• Test Both Positive and Negative Cases: Verify that injection payloads do not succeed and normal inputs work correctly.
• Isolate Test Environment: Run injection tests on a safe test database to avoid data loss or corruption.
• Keep Payloads Updated: Regularly update injection payloads to cover new attack patterns.
• Automate and Schedule: Automate tests and run them regularly to catch regressions early.

Self Check

Where in this folder structure would you add a new SQL injection test for the user registration form?

Key Result

Organize SQL injection tests with clear layers for tests, utilities, config, and reporting to ensure safe, repeatable, and automated vulnerability detection.

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