SQL Injection Lab | THM Walkthrough | By Dharavath Nagaraju

About This Write-up Series

The SQL Injection Lab consists of 10 tasks, each focusing on a different SQL Injection concept or vulnerable web application scenario. Rather than combining everything into a single lengthy article, I've divided the walkthrough into ten separate parts. This approach allows each task to be explained in greater detail, making it easier to understand the concepts, payloads, and reasoning behind every step.

Throughout this series, I will demonstrate how each vulnerability works, explain the SQL Injection techniques involved

Series Overview

• Part 1: Introduction (Current Article)
• Part 2: Introduction to SQL Injection — Part 1 (C_urrent Article)_
• Part 3: Introduction to SQL Injection — Part 2
• Part 4: Vulnerable Startup — Broken Authentication
• Part 5: Vulnerable Startup — Broken Authentication 2
• Part 6: Vulnerable Startup — Broken Authentication 3 (Blind Injection)
• Part 7: Vulnerable Startup — Vulnerable Notes
• Part 8: Vulnerable Startup — Change Password
• Part 9: Vulnerable Startup — Book Title
• Part 10: Vulnerable Startup — Book Title 2

By the end of this series, you'll have a practical understanding of how SQL Injection vulnerabilities occur, how attackers exploit them in different scenarios, and how developers can effectively defend against them using secure coding practices.

Note:_ All demonstrations in this series are performed within the TryHackMe SQL Injection Lab environment for educational purposes only. The techniques discussed should only be practiced in authorized labs or systems where you have explicit permission to perform security testing._

Task 1 Introduction

This room is meant as an introduction to SQL injection and demonstrates various SQL injection attacks. It is not meant as a way to learn the SQL language itself. Some previous knowledge of the SQL language is highly recommended.

The web application can be found at: http://10.48.129.20:5000(opens in new tab)

NB: Please allow a minimum of five minutes for it to deploy.

It is possible to display the SQL queries performed by the application on the challenges by enabling "Show Query" in the top-right menu on http://10.48.129.20:5000(opens in new tab). It is also possible to display tutorial for the challenges by enabling "Guidance".

All the scripts mentioned in the tasks can be viewed and downloaded by visiting the "Downloads" page in the top-left corner on the landing page or visiting

http://10.48.129.20:5000/downloads/(opens in new tab).

Task 2 Introduction to SQL Injection: Part 1

Introduction to SQL Injection

SQL Injection (SQLi) is a web security vulnerability that allows an attacker to inject malicious SQL code into an application's database query. This usually happens when an application directly inserts user input into an SQL statement without validating or sanitizing it.

For example, a login page may generate a query like this:

SELECT * FROM users
WHERE username='user_input'
AND password='password_input';

SELECT * FROM users
WHERE username='user_input'
AND password='password_input';

If the application simply concatenates user input into the query, an attacker can manipulate it.

Authentication Bypass Example

Suppose the attacker enters the following as the username:

' OR 1=1-- -

' OR 1=1-- -

and leaves the password blank.

The query becomes:

SELECT * FROM users
WHERE username='' OR 1=1-- -'
AND password='';

SELECT * FROM users
WHERE username='' OR 1=1-- -'
AND password='';

Here's what happens:

• ' closes the original username string.
• OR 1=1 is always TRUE, so the query matches every user.
• -- - comments out the rest of the query, ignoring the password check.

As a result, the database returns all users, and many vulnerable applications log the attacker in as the first user in the result.

Why -- - Instead of --?

In MySQL, the -- comment syntax is only valid if it is followed by a space or control character. Therefore, attackers commonly use:

-- -

-- -

This ensures the rest of the SQL query is treated as a comment, even after URL encoding.

SQL Injection 1: Input Box Non-String

In this challenge, the application authenticates users by executing the following SQL query:

SELECT uid, name, profileID, salary, passportNr, email, nickName, password
FROM usertable
WHERE profileID = 10
AND password = 'ce5ca67...';

SELECT uid, name, profileID, salary, passportNr, email, nickName, password
FROM usertable
WHERE profileID = 10
AND password = 'ce5ca67...';

The ProfileID field accepts an integer (non-string) value, which is evident because the value is not enclosed in single quotes.

• The application directly inserts the user-supplied ProfileID into the SQL query without proper input validation or parameterized queries.
• Since the input is treated as part of the SQL statement, the database interprets it as SQL code rather than plain user data.
• This allows the logic of the WHERE clause to be altered, potentially affecting how the database evaluates the authentication query.
• The root cause of the vulnerability is the use of dynamic SQL query construction (string concatenation) instead of prepared statements (parameterized queries).
• Using parameterized queries separates SQL commands from user input, ensuring that user-supplied values are treated only as data and cannot modify the SQL query structure.

1. What is the flag for SQL Injection 1: Input Box Non-String?

Answer: THM{dccea429d73d4a6b4f117ac64724f460}

SQL Injection 2: Input Box String

This challenge uses the same query as in the previous challenge. However, the parameter expects a string instead of an integer, as can be seen here:

profileID='10'

profileID='10'

Since it expects a string, we need to modify our payload to bypass the login slightly. The following line will let us in:

1' or '1'='1'-- -

1' or '1'='1'-- -

Bypass the login and retrieve the flag.

2.What is the flag for SQL Injection 2: Input Box String?

1' or '1'='1'-- -

1' or '1'='1'-- -

Answer: THM{356e9de6016b9ac34e02df99a5f755ba}

SQL Injection 3: URL Injection

Introduction

URL Injection is a type of SQL Injection where the vulnerable input is passed through the URL (query string) instead of a login form or input box. If the application directly uses the value received from the URL in an SQL query without validation or parameterized queries, an attacker can manipulate the SQL statement.

For example, consider the following URL:

http://example.com/profile?id=10

http://example.com/profile?id=10

The application retrieves the value of the id parameter from the URL and executes a query similar to:

SELECT * FROM usertable WHERE id = 10;

SELECT * FROM usertable WHERE id = 10;

If the application does not properly validate the id parameter, the user-controlled value becomes part of the SQL query, making the application vulnerable to SQL Injection.

How URL Injection Works

• The application accepts user input through URL parameters (query strings).
• The parameter value is extracted from the URL.
• The application directly inserts the value into an SQL query.
• The database interprets the supplied value as part of the SQL statement instead of treating it purely as data.
• As a result, the logic of the SQL query may change, leading to unintended database behavior.

3.What is the flag for SQL Injection 3: URL Injection?

Answer: THM{645eab5d34f81981f5705de54e8a9c36}

SQL Injection 4: POST Injection

POST Injection is a type of SQL Injection where the vulnerable user input is sent to the server using the HTTP POST method instead of the GET method.

The SQL Injection vulnerability itself is exactly the same. The only difference is how the input reaches the server.

GET vs POST

GET Method

The user input is visible in the URL.

Example:

http://example.com/login?profileID=10&password=test

http://example.com/login?profileID=10&password=test

The parameters are sent as part of the URL.

POST Method

The user input is sent inside the HTTP request body, not in the URL.

Example HTTP Request:

POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
profileID=10&password=test

POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
profileID=10&password=test

The browser sends the data in the request body, making it invisible in the browser's address bar.

4.What is the flag for SQL Injection 4: POST Injection?

Answer: THM{727334fd0f0ea1b836a8d443f09dc8eb}

Conclusion

In this article, we covered the fundamentals of SQL Injection and explored how improper handling of user input can lead to authentication bypass vulnerabilities. We examined different SQL Injection scenarios, including non-string input, string input, URL parameter injection, and POST parameter injection, while understanding how each attack manipulates SQL queries. We also discussed why these vulnerabilities occur and highlighted the importance of using parameterized (prepared) statements and proper input validation to prevent SQL Injection attacks.

This article covered Task 1 (Introduction) and Task 2 (Introduction to SQL Injection — Part 1) of the TryHackMe SQL Injection Lab series.

In the next article, we'll continue with Task 3: Introduction to SQL Injection — Part 2, where we'll explore additional SQL Injection techniques and continue solving the remaining challenges in the lab. Stay tuned for the next part of the series!

Thank you!