SQL Injection Vulnerability

First LAB:

Today, I solved my first lab on the PortSwigger Web Security Academy: “SQL injection vulnerability allowing retrieval of hidden data.” Here is a quick breakdown of how I did it.

1. The Goal

The lab has a category filter. The objective was to manipulate the SQL query to bypass restrictions and reveal all products, including hidden/unreleased ones.

2. Reconnaissance

When clicking a category like Gifts, the URL updates:

https://YOUR-LAB-ID.web-security-academy.net/filter?category=Gifts

The category parameter is passed directly to the database without sanitization.

3. The Exploit

The backend query likely looks like this:

SELECT * FROM products WHERE category = 'Gifts' AND released = 1

To bypass this, I injected a payload that makes the condition always true and comments out the rest of the query. I modified the URL parameter to:

'+OR+1=1--

The transformed query becomes:

SQL

SELECT * FROM products WHERE category = 'Gifts' OR 1=1--' AND released = 1

• ': Closes the SQL string.
• OR 1=1: Always returns true, fetching all rows.
• --: Comments out the rest of the query (AND released = 1).

4. Result

The page reloaded, showing all products and displaying the “Congratulations, you solved the lab!” banner.

Second LAB:

I tackled a new lab focused on manipulating database parameters to access restricted accounts like the administrator. Here is how I solved it.

1. The Goal

The objective of this lab was to bypass authorization checks and access the administrator account or bypass the login mechanism using SQL Injection.

2. Reconnaissance & Testing

While exploring the application, I noticed user-related endpoints in the URL, such as:

https://YOUR-LAB-ID.web-security-academy.net/my-account?id=administrator

The application takes the id parameter and queries the database to fetch user details. Since the input is not properly sanitized, it opens the door for SQL Injection.

3. The Exploit

Instead of just viewing normal user profiles, the backend query looks something like this:

SELECT * FROM users WHERE id = 'administrator'

To manipulate this logic (or bypass authentication if it were a login form), the injection technique forces the database query to return true regardless of strict constraints, or directly target the admin record.

Get Arwahesham’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

By injecting SQL payloads into the parameter (or login fields, depending on the exact lab variant, such as ' OR 1=1--), the query logic is broken in a way that forces the database to grant access or expose the user's session data.

4. Result

Once the injection was successfully processed, the application authenticated or redirected me directly into the administrator’s dashboard, displaying the flag/success message:

Congratulations, you solved the lab!

Third LAB:

I tackled a more advanced SQL injection lab involving UNION attacks on an Oracle database to retrieve the database version.

1. The Goal

The objective of this lab was to exploit a SQL injection vulnerability in the product category filter using a UNION attack to extract the database version string.

2. Reconnaissance

Just like previous labs, the application uses a category filter where the parameter is passed to the backend query:

https://YOUR-LAB-ID.web-security-academy.net/filter?category=Gifts

3. Exploitation Steps

Step 1: Determining the Number of Columns

Before performing a UNION attack, I needed to figure out how many columns the original query returns and which ones support text data. Using the UNION SELECT technique with the Oracle-specific dual table:

'+UNION+SELECT+'abc','def'+FROM+dual--

(Note: Oracle requires every SELECT statement to include a FROM clause, hence the use of the built-in dual table).

Step 2: Extracting the Database Version

Once I confirmed the column structure (two columns supporting text), I replaced one of the columns with the Oracle-specific version query (v$version)

'+UNION+SELECT+BANNER,+NULL+FROM+v$version--

• BANNER: A column in Oracle's v$version view that contains the database version string.
• NULL: Acts as a placeholder for the second column to match the query structure.
• FROM v$version: The system view containing Oracle version details.

Fourth LAB:

1. Lab Objective

The objective of this lab was to exploit a SQL injection vulnerability in the product category filter and use a UNION attack to retrieve and display the database version string.

2. Vulnerability

The product category parameter was vulnerable to SQL injection. By injecting SQL syntax into the category parameter, it was possible to alter the original database query and append a malicious UNION SELECT statement.

3. Identifying the Number of Columns

First, the number of columns returned by the original query was determined. The following payload was used:

'+UNION+SELECT+'abc','def'#

The successful response confirmed that the query returned two columns and that both columns could contain text data.

4. Retrieving the Database Version

Since the lab uses MySQL/Microsoft SQL syntax and the required database version can be retrieved using @@version, the following payload was injected:

'+UNION+SELECT+@@version,+NULL#

The UNION SELECT adds a second query to the original SQL statement. @@version retrieves the database version, while NULL satisfies the second column required by the original query.

5. Result

The injected query successfully caused the application to display the database version string, satisfying the lab objective.

The lab was successfully solved, as confirmed by the “Congratulations, you solved the lab!” message shown in the screenshot.