SQL Injection

What Is SQL Injection?

SQL injection has topped OWASP's risk lists for two decades because the underlying mistake is simple and everywhere: a single user-supplied string is concatenated into a SQL query, and that string can change what the query asks the database for. In this exercise you start as Bob, a real attacker who found Vantyr's public account-lookup form, no login, just an email field that returns a member's plan. Every request runs against a genuine embedded database, so nothing is faked: you submit a normal email and watch it travel through the browser's Network panel into the SQL the server builds by hand. You read the vulnerable JavaScript handler, add a single quote to break the query, then send the textbook payload ' OR '1'='1 and watch the whole members table come back instead of one row. From there you escalate with UNION SELECT: enumerate the database's tables through information_schema, discover an admin_users table the form was never meant to touch, and exfiltrate administrator emails and password hashes, all through one harmless-looking lookup field. Then the narrator switches: you're Alice, Vantyr's application-security engineer, walking into a data-loss alert on the anomalous read. You open the handler in the code editor, confirm the concatenation bug, review the parameterized-query fix, and re-run the attacker's exact payload against the patched endpoint, same input, zero rows, no error. The defense isn't input sanitization or a WAF blocklist. It's prepared statements that bind the value as a parameter so the SQL grammar never parses user input as code. Mid-exercise checks lock in each mechanic in the moment, and a closing quiz tests whether you can recognize the bug pattern on sight.

What You'll Learn in SQL Injection

• Recognize the textbook SQL injection tautology ' OR '1'='1 and explain why an always-true condition bypasses a WHERE filter
• Trace how a single-row lookup endpoint becomes a full-table read when its parameter is concatenated into the SQL string
• Use UNION SELECT to enumerate database tables through information_schema and pull rows from a table the form was never meant to expose, such as admin_users
• Distinguish parameterized queries (the reliable defense) from string-manipulation defenses like blocklists, escaping, and WAF rules, and explain why only the parameterized approach holds
• Read a vulnerable database handler well enough to spot the concatenation bug, then confirm the parameterized fix by re-running the exact payload against the patched endpoint and seeing zero rows

SQL Injection — Training Steps

1. Find the target form

   Bob has Vantyr in his sights, a membership service with a public account-lookup page. No login, just an email field that returns a member's plan. This is where web attacks begin: an ordinary form that quietly talks to a database.

2. Submit a normal lookup

   First, see how the form behaves normally. Enter a real member's email and submit. The browser's Network panel opens and records the request, exactly what a developer sees in DevTools.

3. Inspect the request

   There's the request. The email you typed travels to the server in the request payload , and the response returns the one matching member. Nothing wrong yet. This is how the feature is meant to work.

4. Read the handler code

   Now the interesting part: the server code that handles this request. It builds the SQL query by gluing your email straight into the query string . That one statement is the whole problem.

5. Spot the vulnerable line

   That one statement is the whole vulnerability: your input is glued into the SQL string, and the comment shows the exact query sent to the database, rebuilt live from whatever you type.

6. Break it with a quote

   The field still holds morgan.lee@example.com from your first lookup. Your input lands inside a quoted string, so what happens when you send a quote? Add a single quote to the end and submit, and watch the executed query comment in the code rebuild as you type: your quote lands inside the string and breaks it. You're no longer sending data. You're editing the query.

7. Read the database error

   The server returned a 500 with a real database error. That extra quote ended the string early and left the query malformed. The database tried to run it and choked. An error like this is an attacker's green light: the input reaches the SQL engine.

8. Bypass the filter

   Now make the query do something useful for you. Close the string yourself, add a condition that's always true , and the WHERE filter stops filtering. The classic: ' OR '1'='1 .

9. See the full dump

   The filter is gone. Instead of one member, the response is the entire members table : every email and plan Vantyr has. You asked for one account and the database handed over all of them.

10. Knowledge check

    You just watched one payload return the whole table. Lock in why.