Rolling Thunder Security · Module 05 · SQL Injection

05.01 — Foundations of SQL Injection

Understanding how user input becomes a weapon
Lab Progress
0 / 3

What Is SQL?

Structured Query Language (SQL) is the standard language for interacting with relational databases. Nearly every web application you use — from social media to online banking — stores its data in a database and retrieves it using SQL.

The Core Statements

-- Retrieve data SELECT name, email FROM users WHERE id = 5; -- Add data INSERT INTO users (name, email) VALUES ('Alice', 'alice@acme.com'); -- Change data UPDATE users SET password = 'newpass' WHERE id = 5; -- Remove data DELETE FROM users WHERE id = 5;

Every time you search for a product, log in, or view your profile, queries like these execute behind the scenes.

How Web Apps Build Queries

Here is the dangerous pattern. A developer needs to look up a product by name. They write server-side code like this:

// Python server code (VULNERABLE) query = "SELECT name, price FROM products WHERE name LIKE '%" + user_input + "%'" database.execute(query)

The variable user_input comes directly from whatever the user typed into the search box. The developer assumes users will type something innocent like router. But what if they type something with special SQL characters?

The Single Quote: Gateway to Injection

In SQL, single quotes (') delimit strings. When your input contains a single quote, you escape the string context and start writing raw SQL. The database cannot tell the difference between the developer's query and your injected code. This is the fundamental vulnerability.

-- Developer intended: SELECT name, price FROM products WHERE name LIKE '%router%' -- But if user types: ' OR '1'='1' -- SELECT name, price FROM products WHERE name LIKE '%' OR '1'='1' -- %'

The injected single quote closes the original string. Then OR '1'='1' makes the condition always true. The -- comments out the rest of the query. Result: every row is returned.

A Brief History

SQL injection was first publicly described in 1998 by security researcher Jeff Forristal. Since then it has been the #1 or #2 web vulnerability in every OWASP Top 10 list from 2003 through 2021. Despite being well-understood, it persists because developers continue to concatenate user input directly into queries.

LAB 1 See the Query

You are visiting Acme Corp's online store. The product search page lets customers search by product name. The server builds a SQL query using whatever you type into the search box.

SELECT name, price FROM products WHERE name LIKE '%[YOUR INPUT]%'
Objective

First, try a normal search (like router) and observe how the query is built. Then, type just a single quote (') and observe what happens to the query structure. Understanding how your input becomes part of the SQL is the first step to exploiting it.

Step 1: Type router and click Execute. Notice how it slots neatly into the LIKE clause.
Step 2: Now type just ' (a single quote). Look at the generated query — the string delimiters are now mismatched. This is a syntax error that tells you injection is possible.
COMPLETE — You understand how user input becomes part of SQL.
LAB 2 Your First Injection

Same Acme Corp product search. Now that you understand how the query is built, your goal is to craft input that makes the database return all products, not just those matching your search.

SELECT name, price FROM products WHERE name LIKE '%[YOUR INPUT]%'
Challenge

Inject SQL into the search box that causes the query to return all 6 products in the database. You need to escape the string context and add a condition that is always true.

Think about it: You need to (1) close the string with ', (2) add OR with a condition that is always true, (3) comment out the remaining SQL with --.

Try: %' OR '1'='1' --
Or: %' OR 1=1 --
COMPLETE — You just performed your first SQL injection!
LAB 3 Breaking Out of Context

Acme Corp also has an internal employee directory. The page lets managers look up employees by department name using an exact-match query (not LIKE).

SELECT name, department FROM employees WHERE department = '[YOUR INPUT]'
Challenge

Enter a department lookup that returns all 5 employees regardless of their actual department. The query uses = instead of LIKE, so your approach will be slightly different.

Strategy: Close the string with ', then add a tautology (always-true condition).

Valid solutions include:
' OR '1'='1
' OR 1=1 --
' OR ''='
Engineering' OR '1'='1
COMPLETE — You broke out of the string context!