| Field | Details |
|---|---|
| Module | Cyber Security 101 — Web Hacking |
| Difficulty | Easy |
| Platform | TryHackMe |
| Room Link | https://tryhackme.com/room/sqlfundamentals |
| Date Completed | February 2026 |
| Author | Adwait Joshi |
This is the third room in the CS101 Web Hacking section. Web applications store their data in databases, and the vast majority of web application attacks that result in data breaches involve manipulating database queries. SQL (Structured Query Language) is the language used to interact with relational databases — and understanding it is the prerequisite for understanding SQL injection, one of the most prevalent and impactful vulnerability categories in web application security. This room covers the distinction between relational and non-relational databases, SQL as a language, database and table management, CRUD operations, clauses, operators, and functions — all practiced hands-on against a live MySQL instance.
A database is an organised collection of structured data stored electronically. All web applications that persist data use one. The software layer that manages the database and provides an interface between it and end users or applications is the DBMS — Database Management System. The component that serves as an interface between a database and an end user is the DBMS.
Two primary database paradigms exist:
Relational databases store data in structured, table-based format with fixed columns and rows. Tables have defined schemas — each column has a specified data type. Relationships between tables are established through keys. Relational databases are ideal when data is consistently formatted and integrity between related records is essential. Examples: MySQL, PostgreSQL, Microsoft SQL Server, Oracle. They use SQL for interaction.
Non-relational databases (NoSQL) handle flexible, unstructured, or semi-structured data that may vary in format between records. They are better suited for data with high variability — documents, key-value pairs, time-series data, graph relationships. Examples: MongoDB, Redis, Cassandra. If the data you are storing is unstructured and varies significantly between records, a non-relational database is the appropriate choice.
Relational databases are organised around tables (also called relations):
| Component | Description |
|---|---|
| Table | A collection of related data organised in rows and columns — analogous to a spreadsheet |
| Row (Record) | A single data entry — one instance of the entity the table represents |
| Column (Field) | A single attribute shared across all rows — each column has a defined data type |
| Primary Key | A unique identifier for each row — no two rows can share the same primary key value |
| Foreign Key | A column in one table that references the primary key of another table — establishes relationships between tables |
The primary key ensures every row is uniquely identifiable. The foreign key enables joins between tables — querying data that spans multiple related tables.
SQL is a declarative language for managing and querying relational databases. It is the standard language supported by all major RDBMS products. Its plain-English syntax makes it approachable relative to other programming languages, while its expressive power handles complex queries, aggregations, and multi-table joins efficiently.
The lab machine is accessed via SSH and MySQL is connected with:
mysql -u root -p
# password: tryhackme
SQL provides statements for creating and managing the structure of databases and tables:
CREATE DATABASE thm_bookmarket_db; # creates a new database
SHOW DATABASES; # lists all databases on the server
USE thm_bookmarket_db; # selects the active database
DROP DATABASE thm_bookmarket_db; # permanently deletes a database
Table creation uses CREATE TABLE with column definitions:
CREATE TABLE books (
id INT AUTO_INCREMENT PRIMARY KEY,
title VARCHAR(255) NOT NULL,
author VARCHAR(100),
price DECIMAL(5,2),
stock INT
);
SHOW TABLES; # lists all tables in the active database
DESCRIBE books; # shows columns and data types for a table
DROP TABLE books; # permanently deletes a table
Common data types: INT (integer), VARCHAR(n) (variable-length string up to n characters), TEXT (long text), DECIMAL(p,s) (fixed-precision decimal), DATE, BOOLEAN.
CRUD stands for Create, Read, Update, Delete — the four fundamental data manipulation operations. Every interaction with a database falls into one of these categories.
CREATE — INSERT:
INSERT INTO books (title, author, price, stock)
VALUES ('Network Security', 'John Smith', 29.99, 50);
READ — SELECT:
SELECT * FROM books; # all columns, all rows
SELECT title, author FROM books; # specific columns
SELECT * FROM books WHERE price < 20; # filtered rows
UPDATE:
UPDATE books SET price = 24.99 WHERE id = 1;
DELETE:
DELETE FROM books WHERE id = 1;
The asterisk (*) in a SELECT statement is a wildcard that returns all columns. Omitting a WHERE clause in UPDATE or DELETE affects every row in the table — one of the most common and destructive SQL mistakes.
SQL clauses extend the behaviour of queries:
| Clause | Purpose | Example |
|---|---|---|
WHERE |
Filters rows based on a condition | WHERE price > 10 |
ORDER BY |
Sorts results by a column | ORDER BY price DESC |
GROUP BY |
Groups rows with the same value for aggregation | GROUP BY author |
HAVING |
Filters groups after GROUP BY (like WHERE for aggregated results) | HAVING COUNT(*) > 2 |
LIMIT |
Restricts the number of rows returned | LIMIT 10 |
DISTINCT |
Returns only unique values | SELECT DISTINCT author FROM books |
ORDER BY sorts ascending (ASC) by default; DESC reverses the order. LIMIT is essential for pagination and for avoiding full-table scans in large datasets.
JOINs combine rows from two or more tables based on a related column — the foreign key relationship:
| JOIN Type | Returns |
|---|---|
INNER JOIN |
Only rows where the join condition matches in both tables |
LEFT JOIN |
All rows from the left table, plus matching rows from the right — NULL for non-matches |
RIGHT JOIN |
All rows from the right table, plus matching rows from the left |
FULL OUTER JOIN |
All rows from both tables — NULL for non-matches on either side |
Example — joining books to their orders:
SELECT books.title, orders.quantity
FROM books
INNER JOIN orders ON books.id = orders.book_id;
Comparison operators: =, != or <>, >, <, >=, <=
Logical operators: AND, OR, NOT
Pattern matching: LIKE with % (any sequence of characters) and _ (any single character):
SELECT * FROM books WHERE title LIKE '%security%';
Aggregate functions operate on groups of rows:
| Function | Returns |
|---|---|
COUNT(*) |
Number of rows |
SUM(column) |
Total of numeric column |
AVG(column) |
Average of numeric column |
MAX(column) |
Highest value |
MIN(column) |
Lowest value |
Example combining GROUP BY with aggregate functions:
SELECT author, COUNT(*) AS book_count, AVG(price) AS avg_price
FROM books
GROUP BY author
ORDER BY book_count DESC;
The room runs through eight tasks. All practical work is performed via SSH to the lab machine, interacting with a MySQL instance. Credentials are mysql -u root -p with password tryhackme. The primary practice database is tools_db.
Task 1 (Introduction): Introduces databases as the backbone of modern computing. Notes that SQL knowledge is foundational for both web development and cybersecurity. No answer required.
Task 2 (Database 101): Covers relational vs non-relational databases. Questions: what type of database should be used for unstructured, variable data — Non-relational; what component interfaces between a database and end user — DBMS.
Task 3 (SQL): Covers what SQL is and how to connect to the lab MySQL instance. Questions: what does SQL stand for — Structured Query Language; which type of database does SQL interact with — Relational.
Task 4 (Database and Table Statements): Covers CREATE, SHOW, USE, DROP, DESCRIBE. The practical task requires connecting to MySQL and running these commands against the tools_db database. Questions ask for the output of specific commands — the number of tables in the database, the column structure revealed by DESCRIBE.
Task 5 (CRUD Operations): Covers INSERT, SELECT, UPDATE, DELETE. The practical task requires performing all four operations against the tools_db database. Questions ask for the result of specific SELECT queries — the number of rows returned, specific column values from filtered queries.
Task 6 (Clauses): Covers WHERE, ORDER BY, GROUP BY, HAVING, LIMIT, DISTINCT. The practical task requires applying clauses to filter and sort query results from tools_db. Questions ask for results of ORDER BY price DESC and LIMIT-constrained queries.
Task 7 (Operators and Functions): Covers comparison operators, logical operators, LIKE, and aggregate functions. Questions require running COUNT, AVG, and MAX queries against the database and reporting the results.
Task 8 (Conclusion): Summarises the room and notes that SQL knowledge directly supports understanding SQL injection in upcoming rooms. No answer required.
ssh user@MACHINE_IP
mysql -u root -p
# password: tryhackme
SHOW DATABASES;
CREATE DATABASE thm_bookmarket_db;
USE tools_db;
SHOW TABLES;
DESCRIBE products;
DROP TABLE tablename;
SELECT * FROM products;
SELECT name, price FROM products WHERE price < 50;
SELECT * FROM products ORDER BY price DESC;
SELECT * FROM products LIMIT 5;
SELECT DISTINCT category FROM products;
INSERT INTO products (name, price, stock) VALUES ('Nmap', 0.00, 100);
UPDATE products SET price = 9.99 WHERE id = 3;
DELETE FROM products WHERE id = 5;
SELECT COUNT(*) FROM products;
SELECT AVG(price) FROM products;
SELECT MAX(price) FROM products;
SELECT category, COUNT(*) FROM products GROUP BY category;
SELECT * FROM products WHERE name LIKE '%scan%';
| Concept | Real-World Application |
|---|---|
| SELECT with WHERE clause | SQL injection foundation — understanding how WHERE filters rows is the prerequisite for understanding how SQL injection manipulates those filters; ' OR '1'='1 appended to a WHERE condition returns all rows regardless of the intended filter |
| INSERT statement | Data injection risk — unsanitised user input passed directly into an INSERT statement allows attackers to insert arbitrary records into the database, including admin accounts or malicious data |
| UPDATE without WHERE | Accidental data destruction — omitting a WHERE clause in an UPDATE or DELETE statement affects every row in the table; this is both a developer error and a possible attack outcome of SQL injection |
| DBMS as interface | Attack surface identification — understanding that the DBMS sits between the application and the database clarifies why SQL injection is so impactful: a successful injection bypasses the application layer entirely and communicates directly with the DBMS |
| LIKE operator pattern matching | SQLi blind enumeration — the LIKE operator with % wildcards is used in blind SQL injection to enumerate database contents character by character when direct output is not returned to the attacker |
| JOIN across tables | Credential extraction via SQLi — SQL injection attacks frequently use UNION-based joins to extract data from other tables (such as a users table with username and password hash columns) by appending a SELECT to the original query |
-
SQL is the language of web application data — and SQL injection is possible because user input is concatenated directly into SQL queries without sanitisation. The query
SELECT * FROM users WHERE username = '+ userInput +'becomesSELECT * FROM users WHERE username = '' OR '1'='1'when the attacker provides' OR '1'='1as input. Understanding why this works requires understanding what a WHERE clause does, what string concatenation in SQL produces, and how the database engine evaluates the resulting query. That understanding starts here, with SQL fundamentals. -
The DBMS abstraction layer is both a convenience and an attack surface. The DBMS handles authentication, query parsing, and data access — and it executes whatever valid SQL it receives, regardless of whether that SQL came from the intended application logic or from injected attacker input. There is no inherent distinction from the DBMS's perspective between a legitimate query and an injected one; both are SQL, and both are executed. Parameterised queries and prepared statements are the correct countermeasure because they separate SQL structure from user data at the application level before the query reaches the DBMS.
-
Knowing SQL as a defender is not optional — it is the minimum required to read, understand, and detect attack payloads. A SIEM alert for SQL injection produces a log line containing the injected string. An analyst who cannot read SQL cannot determine whether the injection succeeded, what data was targeted, or what the payload was designed to do. SQL literacy is the difference between an alert that gets closed as "possible SQLi, no confirmed impact" and one that gets correctly triaged as "confirmed UNION-based extraction of the users table."