SQL Injection

What Is SQL Injection?

A user-supplied string is concatenated into a query, and that string can change what the query asks for. Every request here runs against a real embedded database, so nothing is faked. You'll break an account-lookup form with a single quote, return the whole members table with ' OR '1'='1 , then use UNION SELECT and information_schema to pull administrator emails and password hashes out of it. The fix binds the value as a parameter so the SQL grammar never parses input as code. Not sanitization, not a firewall blocklist.

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.