In the previous lesson, you used SQL injection in the login form to bypass authentication and sign in as the administrator without knowing the password. This lesson uses the same underlying defect for a different goal: reading data from tables the endpoint was never meant to expose.
About this category: every lesson in the Server-Side Injection category shares the same root cause — the application passes untrusted user input to an interpreter without enforcing a hard boundary between data and code. The interpreter (a SQL engine, a shell, a template engine, a file loader, or a document database) then treats the attacker's input as executable instructions rather than inert values. The fix is always the same principle: pass user input as data into a fixed structure, never build executable code by string concatenation. In this lesson that principle applies to a SQL query builder; later lessons in this category apply it to other interpreters.
The OWASP Top 10 places this class of finding at A03:2021 - Injection. The attack surface in this lesson is the product search box, but the technique generalizes to any endpoint that concatenates user input into a SQL statement (builds the query as a text string by gluing the input directly onto SQL keywords — for example, "SELECT ... WHERE name = '" + searchTerm + "'" — rather than passing it as a separate bound parameter). Throughout this category, the term sink refers to the point in server code where untrusted input meets a sensitive operation — in this lesson, the SQL query builder.
SQL quick reference: a SELECT statement reads rows from a database table — for example, SELECT email, password FROM Users fetches every user's credentials. The search endpoint runs a query shaped like SELECT * FROM Products WHERE name LIKE '%apple%'. The UNION clause appends a second SELECT to that result, allowing an attacker to pull rows from a completely different table through the same response.
In this lesson you will:
- Observe how the product search endpoint translates a search term into a SQL query.
- Probe the endpoint with a minimal payload that confirms the input reaches the SQL interpreter as code, not as data.
- Construct a UNION-based SQL injection that appends a second SELECT against the Users table, dumping every user's email address and password hash through the search response.
- Distinguish UNION-based extraction from authentication bypass, and understand why parameterized queries close both classes simultaneously.
Estimated time: fifteen to twenty minutes.
Prerequisites: authentication-login for the first SQL injection example, databases-sql-fundamentals for SELECT and WHERE clauses, and browser-recon for observing the search request. You do not need an existing account for this lesson; the search endpoint is reachable anonymously.
Scope reminder: the payloads in this lesson read the entire users table from a database you do not own in production deployments. Restrict your practice to the embedded NovaCart application provided by this course. Running these payloads against a third-party application would constitute unauthorized access to data and is illegal in most jurisdictions.
When you are ready, send the Continue signal.