WebGoat is a deliberately vulnerable web application built by OWASP for security training. In a classic WebGoat SQL injection exercise, a user logs in with an employee name (Smith) and a transaction authentication number (3SL99A). Normal login: Get Department returns the department for Smith with that specific authentication number.
The injection: The attacker leaves the employee name as Smith but modifies the authentication number field, adding: 'OR'1'='1
The query the application sends becomes:
SELECT * FROM employees WHERE name='Smith' AND auth='3SL99A' OR '1'='1'
Because OR '1'='1' is always true, the database returns all records for all employees — not just Smith. The attacker now sees every employee, every department, every authentication number in the database. No additional software. No network intrusion. One modified form field.
What this demonstrates: SQL injection does not require special tools or network access. A browser and knowledge of the injection syntax is sufficient. The attack surface is every form field that touches a database.
A login form has two fields: username and password. The application builds the query:
SELECT * FROM users WHERE username='[input]' AND password='[input]'
The injection: The attacker enters ' OR '1'='1'-- as the username and anything (or nothing) as the password.
The query becomes:
SELECT * FROM users WHERE username='' OR '1'='1'-- ' AND password='anything'
The double dash (--) is a SQL comment. Everything after it — including the password check — is ignored. The OR '1'='1' makes the WHERE clause always true. The database returns the first user in the table — often the administrator account — with no valid password required.
Impact: The attacker is logged in as the first user in the database, often with full administrative privileges. No credentials needed. No brute force. One crafted input string.
A product search form uses the query:
SELECT name, price FROM products WHERE category='[input]'
The injection: The attacker enters electronics' UNION SELECT username, password FROM admin_users--
The query becomes:
SELECT name, price FROM products WHERE category='electronics' UNION SELECT username, password FROM admin_users--
The UNION combines the product results with the admin_users table. The page displays products — and also displays every admin username and password hash alongside them.
What this demonstrates: SQL injection can reach tables completely unrelated to the original query. An attacker who finds injection in the product search can use UNION to extract data from any table in the database — including credential tables.
Scenario: A security analyst reviewing web server logs finds entries containing the string OR 1=1 in the URL parameters of requests to the customer search page. What does this indicate?
Answer: These are SQL injection attempts. The OR 1=1 (or equivalent tautology) is one of the most recognizable SQL injection signatures. The attacker is testing whether the application passes user input to the database without validation. If successful, the query would return all records rather than the intended filtered result. The analyst should check whether the database returned abnormal result counts for these requests and whether the parameterized query controls are in place.
Scenario: An attacker successfully injects SQL into a web application and attempts to run '; DROP TABLE customers--. The injection executes but no tables are deleted. What prevented the deletion?
Answer: The database account the application uses does not have DROP TABLE (or DDL) permission. The principle of least privilege was applied — the web application's database account was granted only SELECT permission on the tables it needs to read. Even though the SQL injection itself succeeded (the query was not parameterized), the attacker's command was blocked by the database's permission system. This illustrates why least privilege is a critical defense-in-depth layer: it limits the impact of successful injection even when parameterized queries are absent.
Scenario: A developer is asked to fix a SQL injection vulnerability in a login form. They suggest adding a web application firewall to detect injection patterns. A security architect replies that the WAF alone is insufficient. Who is correct, and what should be done?
Answer: The security architect is correct. A WAF detects known injection patterns at the network layer but can be bypassed through obfuscation, encoding variations, or novel payloads. The fundamental fix is parameterized queries (prepared statements) in the application code — separating SQL structure from user data so no user input can ever be interpreted as SQL commands, regardless of content. The WAF is a valuable supplementary layer but cannot substitute for fixing the root cause in the application code. The correct approach: fix the code with parameterized queries first, then add the WAF as an additional layer.
Scenario: A question asks: "An attacker inserts malicious commands into an HTML input field that are passed to a backend database and executed. Which attack type is this?"
Answer: This is SQL injection — a specific type of code injection. Code injection is the broader category: inserting executable code into a data stream. SQL injection is the specific type where the target is a relational database using SQL. On the exam, if the scenario describes input being passed to a database and executed as a query, the answer is SQL injection (SQLi) — even if the question framing mentions "code injection" as the category. Know both the category (code injection) and the specific type (SQLi) to answer questions at either level of abstraction.