Injection

What Is Injection?

Untrusted input is concatenated into a query an interpreter then parses, so the input stops being a value and becomes part of the instruction. You'll escalate a catalog search endpoint in three moves: a single quote raises a raw SQL error that echoes the query back, an always-true condition strips the published filter, and UNION SELECT reaches another table for account emails, bcrypt hashes and roles. The fix is a bound parameter, so the database compiles the statement first. Returning a raw SQL error also hands an attacker the map.

What You'll Learn in Injection

• Recognize SQL injection: a request parameter concatenated into a query the database then parses, so the input can rewrite the query and reach data the endpoint never intended to return
• Read the escalation from a single-quote probe that leaks a SQL error, to an always-true condition that strips a filter, to a UNION SELECT that dumps a different table entirely
• Understand that injection does not depend on stolen credentials or missing authentication; an ordinary, fully authenticated account can inject through any input the server treats as code
• Apply the fix: use parameterized queries or prepared statements so the value is bound separately and treated as data, rather than hand-written escaping or blocklists of dangerous characters
• Avoid leaking raw SQL errors to clients, and audit every endpoint that builds a query, command, or template from input for the same concatenation pattern

Injection — Training Steps

1. An ordinary buyer seat

   Wexlar runs a wholesale marketplace, and it hands out self-serve buyer accounts to anyone who signs up. Bob took one, with a throwaway identity. His seat is a plain buyer: browse the catalog, place orders, nothing privileged. He opens the developer console to see what the account is and what the API offers.

2. One search box

   Nothing in Bob's account is privileged, so there are no admin functions to reach. The one input that interests him is the catalog search: it takes whatever he types and runs a name match against the products database.

3. A normal search

   Bob starts with an ordinary search to see the endpoint working and learn its shape. The search takes a q query parameter and returns the products whose name matches.

4. Working as intended

   The search behaves exactly as expected. Three published laptops, only the fields a buyer should see.

5. Append a single quote

   The oldest injection probe there is: Bob appends a single quote to his search term. If the term is being searched for as a value, a search for a name with a quote in it simply returns nothing. If it is being concatenated into SQL, the stray quote will break the query.

6. The query, broken open

   One extra character crashed the endpoint, and the error handed Bob the confirmation he wanted.

7. Rewrite the filter

   Now that Bob knows the term becomes part of the query, he stops breaking it and starts steering it. He crafts a term that closes the string, adds a condition that is always true, and comments out the leftover end of the original query.

8. The whole table

   The filter that limited the search to published products is gone, and the response proves it.

9. Reach another table

   Reading every product is bad; reading tables the search was never meant to touch is worse. Bob uses a UNION to append rows from a different table onto the results. Postgres only accepts a UNION whose columns match the product query in number and type, so he packs each account's email, password hash, and role into the text name column and fills the two number columns with 0 . The AND false in front empties the product half, so only the stolen rows come back.

10. The credential store, in a search result

    The rows that came back are not products at all.